More and more CIOs and enterprise IT managers are under pressure to get some portions of their IT landscape onto public clouds, notably AWS. Typically, the first step in their journey is an assessment of the existing app landscape, and to segment and classify apps that are feasible for cloud migration. The actual migration may be simple lift and shift, a minor re factor, or a complete re architecture, depending upon the application technology and the benefits of moving it to cloud. These approaches are becoming common, with lots of cloud migration vendors and professionals adopting it. However, the migration itself offers an opportunity for the IT to streamline and standardize their application landscape. Aspects of driving standardization, base lining criticality, redefining development/QA usage and revisiting security guidelines are worth considering prior to migration of the application landscape, as it will ensure that the cloud move is robust, stays relevant and delivers the expected benefits. These aspects are over and above the business, technical and operational related facets that IT professionals consider while assessing cloud migration feasibility.
One such aspect is standardization of the software estate. Large enterprises often have offices in many geos, with IT resources being provisioned and managed by local IT teams or local datacenter providers. This tends to cause a sprawl in the software estate, with different versions of operating systems, databases & middleware being used. This is normally dictated by the applications run (typically supported by local vendors), vendors selected (both of infrastructure as well as support) and the preference of application teams to refresh to the latest versions.
While migrating such scores of applications to cloud, it is worthwhile to take stock, define and restrict the versions to a minimum, especially when moving to AWS. One approach is to define a recommended software stack version and a minimum software stack version. The idea is to push application teams to conform to the recommended software stack version, and give an exception to fall back to a minimum software stack version.
For example, a recommended software stack version can be Windows 2012 with SQL 2012, while the fall back version may be Windows 2008 with SQL 2008. The advantage here is that AWS offers all these versions at the same cost. Hence it encourages application teams to look at application upgrades and refreshes, without worrying about the base software upgrade costs. And it makes it easier for the enterprise IT to ensure upgrades and security patches are completed on time with the ongoing support for the current versions.
The standardization exercise is best done after analyzing a significant part if not the entire estate. This is to ensure that the standardized estate is small and manageable, and does not have many variations that will make manageability difficult. The standardization should be done with an aim to publish a catalog of software’s to the various application teams that they can use for existing and newer applications. This is an important step for Enterprise IT towards delivering IT as a Service.
