Overview

In the BFSI enterprise space, organisations are likely to have a sprawling digital landscape of their existing systems. A lot of these might also be legacy systems that have been around for a long time, and systems that are running on their on-premise data centers on manually provisioned and maintained infrastructure. These are systems that cover a lot of scope, complexity, functionality and are often tightly coupled.

So when these organisations think of cloud adoption, and migration of existing systems to the cloud, it’s better to plan appropriately, and look at incremental gains in migration instead of trying to do everything all at once. We talk about systems having “Cloud Readiness”, essentially meaning that what is deployed in the cloud infrastructure can actually be deployed there, leverage the advantages of the cloud effectively, and can be migrated with minimal or no impact to business operations. There are a few important points that need to be considered to this end. This post is a continuation along the series on Cloud Adoption and Migration to talk through what considerations need to be made when evaluating the technical aspects of the organisation’s digital platforms for cloud readiness. This post will focus on evaluating application stacks for cloud readiness, and using that to drive the migration strategy.

Reviewing Readiness of Application Workloads

In order to be able to get started with Cloud Infrastructure, it’s good to start with mapping out the existing systems currently in use. While it is tempting to start by replicating the data-center setup in the cloud, this is sub-optimal and often leads to underwhelming results, and becomes an expensive white elephant soon.

Instead, it’s useful to look at what are the application stacks and associated digital assets we would look to move to the cloud, and which ones unlock business value faster. With that lens in mind, we first need to assess a few aspects of the application stack. It’s also instructive to refer to approaches like 12 Factor Apps that set out guidelines for cloud-native software-as-a-service approaches to building applications.

These are the various items we need to review in order to determine cloud readiness of our applications:

1. Architecture Review

• Scalability: Determine if the application can scale horizontally (adding more instances) or vertically (adding more resources) in response to demand. Cloud environments typically require applications to scale efficiently.
• Modularity: Assess whether the application is modular, meaning it can be broken down into smaller, independent components (e.g., microservices) that can be deployed and managed separately in the cloud.
• Statelessness: Check if the application is stateless or can be modified to be stateless, as cloud environments often favor stateless applications that don’t rely on local storage or session data.

2. Technology Stack Compatibility

• Cloud-Native Technologies: Evaluate whether the application uses cloud-native technologies such as containers, serverless functions, or managed databases. Applications built with these technologies are generally more cloud-ready.
• Legacy Dependencies: Identify any legacy technologies, proprietary software, or custom integrations that might not be supported in the cloud or require significant modification.

3. Data Management

• Data Decoupling: Determine if the application’s data layer is decoupled from the application logic. In a cloud environment, data should ideally be stored in cloud-native databases or storage solutions.
• Data Transfer and Synchronization: Assess how the application handles data transfer and synchronization, especially if moving to a cloud environment with geographically distributed users or services.

4. Performance and Latency

• Latency Sensitivity: Evaluate how sensitive the application is to latency. Applications with real-time processing requirements might need special consideration when moved to the cloud.
• Bandwidth Requirements: Assess the bandwidth requirements for the application, as high bandwidth needs can impact performance in a cloud environment, especially with data-intensive applications.

5. Security and Compliance

• Security Controls: Review the application’s security controls and determine if they align with cloud security best practices, such as encryption, identity management, and logging.
• Compliance Requirements: Check if the application meets compliance requirements for your industry (e.g., GDPR, HIPAA) when hosted in a cloud environment. This includes data residency, encryption, and auditability.

6. Operational Considerations

• Monitoring and Logging: Determine if the application has built-in monitoring and logging capabilities that can be integrated with cloud-based monitoring tools like AWS CloudWatch, Azure Monitor, or Google Cloud Operations.
• Deployment Automation: Assess whether the application’s deployment process can be automated using CI/CD pipelines. Cloud readiness often requires the ability to automate deployment, scaling, and updates.
• Disaster Recovery: Evaluate if the application has disaster recovery capabilities that can be adapted to a cloud environment, such as automated backups and multi-region failover.

7. Application Dependencies

• External Integrations: Identify any dependencies on external systems, databases, or services that might not be easily accessible or compatible with the cloud. Consider how these integrations will be maintained or replaced in the cloud.
• Versioning and Updates: Check if the application and its dependencies are up-to-date and can be easily updated. Outdated software can present challenges during migration.

8. Cost Considerations

• Cost Efficiency: Estimate the cost of running the application in the cloud, considering factors like compute, storage, data transfer, and scaling. Some applications may not be cost-effective to run in the cloud without optimization.
• Resource Utilization: Assess the application’s resource utilization patterns to identify opportunities for cost optimization, such as rightsizing compute instances or using serverless functions.

9. Pilot Testing

• Proof of Concept (PoC): Run a pilot test of the application in the cloud to identify any issues that might not be apparent in a theoretical assessment. This can help uncover performance bottlenecks, security gaps, or other challenges.
• Load Testing: Conduct load testing in a cloud environment to ensure the application can handle expected traffic and workloads without degradation in performance.

10. Documentation and Knowledge Transfer

• Documentation Review: Ensure that the application is well-documented, with clear instructions for deployment, maintenance, and troubleshooting in a cloud environment.
• Training: Assess whether the IT team has the necessary skills and knowledge to manage the application in the cloud or if additional training is required.

‍

Driving decisions based on the Application Requirements

‍

‍

Once we have done a review of our application stacks, we can then take a call on whether the applications are ready to move as-is. If they cannot move as is, we need to determine what needs to be done to make them cloud ready. This should be followed by estimating the effort and cost of updating the applications, and the benefits of having these applications modernised.

Once the application stacks are determined, we then map out the infrastructure requirements for these apps and work on automating and provisioning them as needed in the cloud. This allows for a staged, incremental approach to migrating to the cloud, and is more efficient in terms of cost, effort and is more likely to succeed. Future posts will dive deeper into the topic, and cover other aspects we might need to review.

‍