Separation of Concerns is a well-known concept in application architecture. Over the years, application structures have evolved from monolithic to modular, using techniques such as encapsulation and abstraction to reduce coupling and increase cohesion. The purpose of doing so is quite simple – it yields software systems that are easier to understand, change, and enhance.
Within a monolith, all changes must be made in context of the whole. As that whole increases in size, the ability to understand the effect of a given change decreases and risk increases, even in the absence of complex logic. Complex processes, obviously, compound these effects.
With all this in mind, competent and responsible architects encapsulate, modularize, and partition code. Likewise, databases shared across multiple applications are seen as the anti-pattern that they are. Unfortunately, some seem to forget the principles and benefits of separation of concerns when it comes to infrastructure.
Without a doubt, server consolidation can save on licensing, administration, and hardware costs. However, the concepts of coupling and cohesion apply to the platform as much as the applications it supports. All applications sharing the same hardware environment are subject to a form of coupling. Whether that coupling is logically consistent (cohesive) or not can impact operations and customer satisfaction. It might be uncomfortable explaining why a critical line of business application is unavailable (if only briefly) because of a bad release of the intranet suggestion box.
Maintaining application cohesion on the platform also enhances your ability to keep the platform current. An environment hosting a family of applications maintained by the same team should be more easily maintained than a grab bag that’s home to a wide variety of systems. As with any chore, the more painful it is, the less likely it will be done. Failing to keep the platform up to date is a fast track to legacy status.
Paying attention to the following factors can assist in keeping platforms cohesive, maintainable and healthy:
- Organizational Concerns: As noted above, systems sharing a homogeneous audience as well as the same (or at close on the org chart) support team will make for better roommates.
- Technology: Some applications (particularly platform applications such as database software) don’t play as well with others, preferring to control the lion’s share of resources. These are poor candidates to be deployed to the same host/cluster as others applications. Likewise, dependency conflicts will affect hosting decisions. Stability is also an important factor – less stable systems should be isolated.
- Security: Not hosting applications with different security profiles on the same machine(s) should be self-evident.
- Criticality: Those responsible for disaster recovery will be much happier if the high-priority systems are not intermingled with the low-priority ones.
- Resource Utilization: Usage of CPU, memory, storage, and network bandwidth should all be accounted for to avoid overloading the infrastructure. The fact that this utilization isn’t a steady state should also be borne in mind. Trends may edge up or down over time and some applications may have periods of higher than normal use.
While it doesn’t help with licensing and administration costs, virtualization can provide isolation without driving up hardware costs. Where appropriate, cloud offerings may also help with managing licensing, hardware, and (depending on the solution) administration costs. In all cases, savings must be evaluated against risks in order to get the full picture.
Re-posted from Form Follows Function
