Introduction
The cloud is the future. Azure is the best cloud solution provider.
Azure helps you focus on core functionality and keeps you free from the pain of maintenance of infrastructure, security, and other activities.
Infrastructure in itself is a big world. It involves whole DevOps process, application availability, server maintenance and lot more. This involves a huge cost in terms on time, resources and money. Every organization wants to avoid this overhead.
So as a solution, every organization is in the mode of moving their application to the cloud. I wanted to share my experience on this and put forward the areas where the Architects should focus on while migrating the applications.
This article is majorly focusing on Lifting and Shifting applications to Azure, but can be used for technology upgradation and PaaSification applications as well.
Normally all information is available on internet, but I have listed them here in one place.
These are the activities Architect/Developers should focus on while trying to migrate their application to Azure.
Discovery and Analysis
There can be multiple ways of analyzing the applications. But I relied on manual analysis.
As a first step toward PaaSification, analyze all applications and list them in excel on below criteria.
Dependencies
Dependencies can be all components which applications are consuming or interacting with, which can or cannot be migrated to Azure. This activity has to be done very cautiously, as all future decisions have to be made on this analysis. Below are few areas which you should make a note of while analyzing
- Assembly/Dll
- OnPremise/Third Party services
- Database/Connection String
- OnPremise Shared folders
- SSIS/SSRS Packages
- MQ
- Third party DB like DB2/mainframe
- Logging
- Monitoring
- CICS/Mainframe
Development
Before we start working on migration of the code, we need to capture all configurations which have to be replaced with their Azure counterparts. Below are the items I recommend to capture from code/configurations
- Session Management
- Configurations details.
- Authentication Mechanism
- Credentials for any resource access.
Non Functional Requirement
While migrating, we need to ensure application performance should be same as that of existing. To ensure that, we need to capture beforehand the legacy application details on.
- Load Testing use case
- Performance SLA
- Metrics to get an idea of application usage.
Infrastructure
We need to capture on which environmenst the legacy application is deployed to, to ensure when we move to Azure. The servers are of the same configuration. A few things which have to be captured are:
- Environments
- Server Configurations
- Disaster Recovery
Data Security
When we look to work on migrating an application along with its DB, we need to ensure application user data is not compromised. So we should take this into consideration.
- Accessibility Details
- PII/PCI
Functional
Any functionality which can be impacted due to the application getting moved to Azure should also be taken note of. Impact happens because the resources being used for this functionality are not reachable from Azure.
DevOps
All DevOps activity should be taken a note of, so that it works the way it should be after Azure migration.
- Configuration management
- Branching strategy
- Deployment process (CI/CD)
- Alerts
Production Support
While the application moves to Azure, we need to provide support for issues in hyper care period. We should plan for it.
Implementation Phase
There are lots of activities which need to be taken care off. But it depends on the organization and the standard followed inside it.
I am putting forward a generic activity list which is supposed to be followed for Azure migrations.
Application Architecture
After the analysis is completed the Architect needs to compile all dependency information. He needs to brainstorm the dependencies being listed. He or she needs to analyze if all dependencies can work from Azure or not.
This further needs to be discussed with other architects and senior members of the project, and consensus should be reached.
Topology Creation, Review and Approval
Once we have solutions for all such dependencies, the architect has to propose a Topology which lists down all components of the applications along with the DB. Points which should be covered in Topology are:
- Azure components
- Authentication Mechanism
- DB
- Services
- On Premise dependencies
- Firewall
- Network Security
- Load balancer
- DNS
- Azure Subscription Details
- Application consumers
- Third Party Dependencies
- Workload instances an counts
Once the topology is ready, it has to be internally reviewed. It has to be presented to the organization's security and architecture team for approval. If all is well, Topology gets approved with a few suggestions.
Once the topology is approved, you need to start working on the below items.
Resource Creation and Provisioning
The organization's cloud architecture team has to give you a subscription for your project. Based on the subscription, you need to go ahead and create the required resources, so that they can be readily used for deployment
VSTS
You need to migrate the code from on premise repo to VSTS . This requires analysis of legacy folder structure and makes it fit into VSTS repository structure.
Authentication
Based upon your decision to use ADFS/AAD for migration, you need to register you applications in either of it. And keep the details handy to be put in application configurations files
Azure-i-fication.
Based on which service you have chosen on Azure, PaaS Or IaaS, you need to modify your application configuration details.
You can choose ARM template for deployment, if you are on V2 offering of Azure.
Otherwise, if you choose the V1 offering, adding cloud service to your project will be required.
Release/Build Definitions
New build and release definitions have to be configured for applications which have to be moved to Azure.
As per industry standard, there are two build definitions created:
- CI Build
- Release build
Further, release pipeline is created for smooth deployment to all environments.
DB Migrations
DB migrations require a careful examination of Data which is present in the DB.
- All fields of each table have to be analyzed for PII/PIC data present.
- Data at rest has to be encrypted with TDE (Transparent data Encryption)
- Encryption for data at the move has to be identified for all PCI and PII data. Any tool like HP voltage has to be used for encryption of data at move.
DB migration to Azure is normally taken care of by DBA, but code changes are required from the developer side to change the IP address or Server name. Server name has to be replaced by fully qualified server name.
DBAs have to implement TLS to enable secure data during the move.
Firewall Openings
For any on premise connectivity, a firewall has to be put in place so that all required dependent on premise resources can be accessed.
Config Credentials Values
In legacy applications, the third party resource access credentials were kept in web.config files.
If you don’t take care of it, while deploying, such credentials will be prone to threats.
So before deploying, you need to make sure to all such config values are encrypted.
POST PaaSification Activities.
Different organizations use different ways of maintaining health checks for their applications.
You can use Applications Insights, OMS, Dynatrace, Splunk for configuring health alerts of your application and resources.
Health check for resource availability should also be put in place, which will load balancers to redirect the traffic to available resources in case of DR.
Disaster Recovery, High Availability and Back Up
To ensure applications are available at all times when issues such as natural calamities, network outage, data corruption etc., occurs, a well thought out plan should be put in place.
Resource should be provisioned on more than one location. So that in case of down time, ILB/Traffic manager can redirect the request to available resources.
DB Backup should be planned with the help of DBA, so that in case of data corruption, DB can be rested from back up taken.
Conclusion
Each of the above topics can be discussed in more detail. But the idea of presenting it here was collective information to be put at one place, based upon my experience.
This would definitely give an insight to Developers/Architects to speed up their organization's cloud journey.