If you would like to read the first part in this article series please go to Considerations for Distributed Applications in Virtual Environments (Part 1).
Introduction
In the first article in this series, I posed the question of whether it is better to deploy enterprise class applications in a distributed manner whenever possible, or if it is better to try to consolidate those applications. In that article, I spent a considerable amount of time talking about the advantages that could potentially be achieved by consolidating applications into single virtual machine deployments.
Although there are undeniable benefits to performing consolidated application deployments, it is generally advisable to use distributed deployments instead, especially in larger organizations. Just as there are advantages to performing consolidated deployments, there are advantages to distributed application deployments as well. In my opinion, the advantages presented by distributed deployments usually outweigh the advantages that you might achieve through consolidation.
Easier Troubleshooting
One advantage to performing distributed application deployments is that it can make the troubleshooting process a lot easier when things go wrong. Anybody who has worked with computers for a significant amount of time has seen situations in which a problem was caused by something completely bizarre, and totally unexpected. With this in mind, consider what might be involved in troubleshooting a consolidated application.
Suppose that a particular application had six main components, and that all six of those components were installed on a particular virtual machine. Now suppose that one of those components started having some serious problems. It is entirely possible that the problem that you are noticing is a symptom of a much deeper problem. The root of the problem might not have anything to do with the component that is actually exhibiting symptoms. It could be that one of the other components had a memory leak and is depleting the seemingly problematic component of necessary resources.
When you perform a distributed deployment, each virtual machine is hosting a piece of the application as a whole. If an application has six components, the application might be distributed across six separate virtual machines. These virtual machines represent an isolation boundary. If a problem occurs within a virtual machine, then you can be sure that the problem is related to something inside of that virtual machine (at least assuming that you can rule out communications problems between VMs). If the problematic VM is only performing a single task then the problem will be much easier to troubleshoot than it might be if there were a number of other services running on the VM.
Lower Support Costs
Any time that you can make the troubleshooting process easier, there is also a good chance that you are going to reduce support costs. Some might be quick to point out that deploying an application in a distributed manner can increase licensing costs, and that any reductions in support costs might be offset by increased licensing costs. Even so, there are a couple of things to think about.
For starters, the additional licensing costs might not be as expensive as you would expect. For example, if you were to deploy Hyper-V on top of Windows Server Data Center Edition, then you can have an unlimited number of virtual machines running on that server, so long as each virtual machine is running the same operating system as the host. As such, you can save quite a bit of money because you are not required to license each virtual machine’s operating system.
Another thing to think about is that assuming that you buy perpetual licenses, licensing is a one-time expense. Support costs on the other hand, are ongoing. That being the case, it is at least plausible that the money you save on reduced support costs could eventually offset the increases in licensing costs.
Better Security
Distributed applications can also be more secure than consolidated applications. There is a rule of computing that states that the more code that is running on a system, the greater the chance that the code will contain an exploitable security vulnerability. As such, one way of reducing the potential vulnerability is to reduce the server’s footprint by eliminating as much unnecessary code as possible.
If this philosophy holds true (and in my experience it does) then it means that it is better from a security standpoint to have several virtual machines with small footprints than a single virtual machine with a large footprint. Besides, think about what would happen if a virtual machine were compromised. If a virtual machine were running a very limited amount of code, then the attacker might not be able to do as much damage as they could potentially do if the virtual machine were running a consolidated application.
Granular Resource Control
Another reason why it might be better to perform distributed application deployments whenever possible, is because doing so can sometimes allow you to achieve more granular control over hardware resource consumption. The reasoning behind this one is a little bit tricky, but bear with me.
Resource control all comes down to workload predictability. For line of business applications, there is rarely any such thing as a linear workload. Instead, there are performance spikes throughout the day. That being the case, hardware requirements can be defined as a range, rather than being defined as an absolute value. For example, an idol application may consume 2 GB of memory, whereas the same application might consume 3 GB of memory during periods of heavy usage.
Now let’s go back to my earlier example in which a particular application was made up of six separate components. Assuming that all six components are capable of being deployed individually, then there is going to be a performance range for each component. Each component will have a low value and a high-value for things like memory consumption, CPU usage, and disk I/O.
When each component is deployed to a separate virtual machine, it becomes relatively easy to track hardware usage and to define a virtual machine hardware profile that allocates the necessary resources, without wasting resources. The same task of analyzing hardware usage and provisioning the correct hardware becomes a lot more difficult when all of those components are lumped into a common virtual machine. The range between periods of high activity and low activity can also become a lot higher, which makes it more difficult to allocate hardware resources without wasting available resources in the process.
Scalability
Of course the best reason of all for deploying applications in a distributed manner, is that doing so makes it much easier to achieve scalability. It is difficult to scale an application that is subject to the limitations of a single virtual machine.
Often times applications that are designed to be deployed in a distributed fashion also provide some sort of built-in redundancy that can help keep the application running in the event that one of the application servers were to fail. Exchange Server for example allows mailbox database copies to be placed on multiple mailbox servers within a Database Availability Group. That way, Exchange Server can keep running even if a mailbox server fails.
Conclusion
It’s usually better to deploy applications in a distributed manner whenever possible. Although the licensing costs for doing so might be higher than they would be for a consolidated deployment, the benefits may outweigh the cost. Distributed deployments tend to be more scalable, more fault-tolerant, and easier to troubleshoot. For an administrator, all of this means that distributed applications make it a lot easier to comply with the required Service Level Agreements for your organization.
If you would like to read the first part in this article series please go to Considerations for Distributed Applications in Virtual Environments (Part 1).
