Application and Infrastructure Battle Lines
- By Rick Vanover
For infrastructure administrators, there has always been a gray area where the infrastructure stops and the application teams take over. I have experience in two arrangements. The first is where the infrastructure teams stop at the operating system, and the second is when they go far into the applications. In most situations, it's a cleaner arrangement when the infrastructure teams offer support at the OS and below.
Of course, IT personnel in smaller IT shops need to be jacks-of-all-trades and know everything about everything. I don't have an answer for that, unfortunately. However, mainstream configurations that include virtualization are ripe for clearly defined roles within an infrastructure practice. The difficult decision is determining the handoff point from an infrastructure owner to an application owner. In discussions with other IT administrators and managers, it's apparent that these lines are not clear in many organizations. If you don't have defined service-level agreements, it may be even more difficult to draw the authoritative line in the sand on where infrastructure stops and application support begins.
It may be time to rewrite the map in a way to implement the cutoff point between infrastructure support and application support. You have to work with the application owners, of course, but having defined divisions provides operational efficiencies when applied fully to the organization. This can include automated alerting, paging, support operations and update management for applications. As an infrastructure administrator, chances are you don't want to be bothered with pages or e-mails about an application issue that you can't fix, or one that has an impact about which you're unsure. If the dividing line is fully propagated to the organization, the operational benefits can be blissful. Besides, how many pages have you responded to only to find out that the application team was performing a planned change?
Examples of handoffs will vary by requirements, but they generally revolve around permissions as a first line of organization. Application owners may not necessarily have administrative access to the OS, but do have full application rights to develop and support the application. Infrastructure teams may have administrative access to the OS to perform updates and security patching, but generally wouldn't require application visibility on the server-infrastructure side.
These practice points can be provisioned on the virtual infrastructure as well, and in some cases to a more granular level. For VMware and other virtualization environments, there are certain defined roles that provide application owners a self-service view into the workloads that they support. In some cases, it may be necessary to provision the right to even use the virtual power button. While rare, this is an example where the application owners can fully support what's required without involving the infrastructure team. Another permission that can make sense to the role-based approach is allowing media access, such as a CD-ROM, to a virtual machine.
Fine Line, Finer Results
From my experience, I can say that the hard part is getting the arrangements in place. Once the SLA or defined roles are established, you can be in virtual cruise control for your environment with application people doing application things and virtual infrastructure people doing infrastructure things.
Rick Vanover (Cisco Champion, Microsoft MVP, VMware vExpert) is based in Columbus, Ohio. Vanover's experience includes systems administration and IT management, with virtualization, cloud and storage technologies being the central theme of his career recently. Follow him on Twitter @RickVanover.