WavebreakMediaMicro - Fotolia
Change your application support process to juggle cloud and legacy IT
Legacy IT and cloud app architectures demand different application maintenance and support activities, but with some abstraction and automation, they coexist.
You won't move the whole IT organization into a cloud operating model overnight, so it's imperative for team members to manage and operate older, core IT platforms while they simultaneously provision, monitor and optimize cloud workloads.
Typical medium- to large-sized companies spend years with a split of legacy IT and modern platforms. Monolithic enterprise applications run core business processes; new features are built via cloud-native methods to extend the business to flexible web and mobile interactions.
This mix of legacy and cloud IT assets creates a division of application support processes and skills in enterprise shops. The skill sets and activities for the two platforms are totally different, and it's hard to find staff members with skills on tools to run both the cloud-native and host-based enterprise systems.
Enterprise application support clashes with the automation-driven service delivery model of cloud application support. Traditional enterprise IT teams believe that a stable infrastructure state is what enables business applications to work, closing the door on the cloud-native mantra that applications and infrastructure must be failure-tolerant, not failure-proof.
Legacy IT support
Critical enterprise applications demand high reliability and enterprise IT operations teams develop many processes and controls around their platforms and systems. Monolithic application architectures mean that the entire application is either available or it is down, and enterprise infrastructure is optimized for that model. Changes might cause outages; stability comes from slowing down change.
Change management processes prevent unplanned downtime and configuration management databases (CMDBs) record the exact state of the entire system. IT operations staff develop complete knowledge of the infrastructure and applications, rely on established support processes, and have highly developed risk management and mitigation techniques. They're expected to manually return systems to an active state as soon as they break.
Cloud application support
Cloud-native applications usually evolve with incremental changes made on a routine basis. The application architecture consists of small parts, such as microservices, that can fail without taking down the entire application -- many users won't notice these partial outages. Cloud applications are assembled from services delivered by a programmable infrastructure, which requires minimal effort when compared to the host-based legacy IT systems' infrastructure setup. Application developers expect to interact with the services inside of application code. Rather than specifically tailoring infrastructure to accommodate applications, the IT operations teams focus on ways to delivery infrastructure services. This skill set and approach to application maintenance and support is epitomized by site reliability engineering (SRE).
The cloud application support model relies on IT operations team to write software changes so that systems automatically return to a running state after failure or problems.
Make the transition between legacy IT and cloud operations
Fortune 500 and similarly large companies have the scale to keep separate, dedicated teams for legacy IT and cloud operations and support while cloud-native start-ups skirt the problem entirely. For everyone else, a single team must take responsibility for both legacy and modern applications and develop a base of cloud operations knowledge from existing team members who understand the business.
To start on the journey to support cloud application operations alongside legacy enterprise IT requirements, follow these three steps:
- Adopt infrastructure as code methodologies to replace manual processes documented in run books: Define the application's or application components' known-good state in an automation software that uses text-based configuration files. To change the infrastructure, create an updated version of the configuration file, then deploy it again through the automation software. To make infrastructure as code work, choose a tool such as Chef, Puppet or Ansible configuration management, and store configuration files in a source control system, such as Git. The version control repository replaces a CMDB as the source of infrastructure configuration truth, a setup sometimes referred to as GitOps.
- Proceed to have the operations team write or modify software: This programming skill is a crucial part of SRE. Specifically, operations staff should write plugins for the configuration management system so that it handles the legacy applications that don't naturally fit deployment and infrastructure as code updates. With the operations team able to customize configuration management, they can support legacy applications and cloud deployments with less of a maintenance burden.
- Develop application services to deliver alongside infrastructure services: Cloud developers expect to deploy and consume services like databases using APIs rather than help desk tickets. IT organizations should consider a container service, such as one based on Kubernetes, to enable consistent services deployment. Another option for select application workloads is a functions-as-a-service platform, sometimes called serverless, to streamline the connection between developers and the IT infrastructure that supports their applications.
The transition from enterprise to cloud-native application support processes involves a vast change in the services delivered and the techniques required from the operations team. The long life and high value of enterprise IT applications indicate that they will not go away any time soon. The agility and flexibility of cloud-native architectures mean that new development will favor this architecture. For the foreseeable future, IT operations must look after both.
