Enterprise Apps - Migration strategies to the Cloud
Aamar Hussain
Enabling businesses with AI & Data Expertise | Strategic Advisor & Trainer in GenAI, Data, ML | Empowering Global Businesses with Generative AI and Data-Driven Decision Making
In 2009-10 I started part-time masters based at Leeds Met University. During which I started to look at Cloud as a topic of research for my thesis it is since then I have been driving my career increasingly towards the cloud path..at the time I was working at CSC (now DXC) supporting some large accounts predominantly looking at data center related architecture and deals.
Since then I have seen a fundamental shift in organisations IT strategy, moving away from the traditional DC model to a more cloud-based strategy.
Most CIO's would like to do away with the job of keeping the lights on and rather focus on understanding the benefits of the public cloud to help reduce IT costs and fuel innovation for the core business. IT leadership is now focused on adopting cloud as a viable option to provide a reduction in total cost ownership (TCO) of running IT.
"Public cloud adoption is accelerating and public cloud services do, and will, cannibalize IT services spending in the coming years, most notably in the data center," said Bryan Britz, research director at Gartner.
Any impact on TCO requires a large scale application migration from on-premise privately hosted supported data centers to the public cloud. Arriving at a TCO number is difficult when the comparison is not as straightforward for example how do you quantify business agility and utilisation as well as allowing businesses to enter new verticals to find new customers and provide a better experience to existing customers base.
The need for change of mindset
Any cloud migration project or transformation program requires a change in mindset. Major IT project they are typically driven by a large-scale projects mentality for example 'waterfall' mentality ...more like launching a rocket to space
Spend a year or so on building or designing, then procurement phase of acquiring components then testing everything to death before finally getting ready for launch, by the time the rocket is finally launched it ends landing back on earth and it's time to start again.
This approach provides more opportunities to fail, not mention the diverse nature of application portfolio with its own set of interdependencies. When looking at a migration to the cloud you need a break the old habit of doing things in a big bang approach.
The concept I am referring to here is 'iteration', Iteration requires CIO to abandon old habits of the waterfall model, in this new model the data center is broken down into objects and seen as infrastructure as code.
The public cloud allows you to create your DC from scratch with technologies such as Chef, Puppet, CloudFormation, Terraform welcome to the world of software-defined data center allowing you to scale (servers, compute, networks) and since you are using software to build your DC you can iterate fail until you have your desired state.
Moving your first application
The start of the migration journey is critical and your first application will set the tone for the remaining application portfolio rather than taking a basic test or dev application I highly recommend you select a meaningful application which requires all stakeholders to be involved in the process and allow for change in mindset to start, which plays a crucial part in ultimate success of migration and running workloads in the cloud.
You need to get buy-in from key stakeholders in the migration namely: Security, App Owners, Operations, Governance, Compliance, Legal and the exec office
Migration paths and approaches
There are number of migration options which can be adopted they all depend on the nature and specific requirements of the application, age, impact to business, integration dependencies on other applications, non-functional requirements
These are the most common approaches you can consider:
Lift and Shift
More commonly known as 'Re-hosting', this approaches boils down to mapping like for like infrastructure architecture on the 'to-be' cloud platform including the data. It is considered as the easiest form of migration however you won't recognise the real benefits of cloud as the application has not been developed to run on the cloud natively.
Re-platform
The focus here is more around making sure the 'to-be' platform is fine-tuned to enable the application to function/run on the new environment these include
- DNS and Networking changes
- Version upgrades or down-grades of O/S and databases
- Configuration or .INI changes
Refactoring
This is most disruptive of the approaches as it will involve code level changes of the application, this is mostly required for applications which do not quite cloud ready but can work with modification in the code. You need to consider refactoring vs retiring if the cost of re-platforming are starting to outweigh the benefits of retiring and starting from scratch
Retire
There may be certain applications which are required for some non-functional purpose for example compliance or regulatory. There may well be replicated services in the cloud to mitigate the need for this application. The TCO question is important here because if re-platforming or refactoring the application is too time-consuming or costly you may be better suited to retiring.
Replace
Replacing applications is more relevant once you have migrated to the cloud however it could also play a critical part in the initial stages as you may want to consider replacement for some application upfront i.e. if you foresee changes in business model and outcomes you will need to replace the functionality required to achieve the business outcome you are trying to achieve.
Key consideration for this approach is the need for a very close collaboration between the various stakeholders (business process owners, application owners, InfoSec)
Retain
In a large enterprise, you are going to ultimately have to retain some form of your application estate. The key challenge here is how will the retained application estate engage with applications deployed in the cloud, often this is a point of contention.
The retaining piece requires a greater focus on security. Majority of security breaches often occur when there is a back-door access to the retained environment this allows a way into the cloud environment and ultimately impact any applications hosted in the cloud.
Summary
Once you have established which applications can be moved to the cloud you can then start looking at building the 'target' environments in cloud assuming appropriate cloud platforms have been researched and selected based on a number of various criteria list in terms of technical, operations, legal, compliance regulatory.
Hence I said platforms and not a platform you may need to look at more than ONE cloud provider.
Have you come across any of the above?
Driven to make change happen and helping clients make smarter decisions.
7 年Good read. Need to keep in mind the operational side, monitoring reporting slas, business needs too etc ..single pain view of the world..more challanging when more than one platform is in play.. always also need to know what the problem statement is before the answer comes back cloud..