Annapurna Finance migrates to AWS with Workmates

Annapurna Finance Pvt. Ltd. (AFPL) was established in 2009 and is now one of the top ten NBFC-MFIs in India. It has its roots as a part of a not-for-profit entity, Peoples Forum, an NGO, which worked for the development and welfare of unserved sections of society. Annapurna Finance was established with the purpose of serving economically backward clients by bringing them to the mainstream, and providing need-based financial services at their doorstep. Its
objectives have not only been limited to just reach and serving but also by doing financial and technical support to strengthen entrepreneurial skills for effective and efficient undertaking of business activities. Annapurna Finance, over the years, has continued to innovate in its products and delivery mechanisms, to make the whole product life cycle of micro-credit as relevant as possible for its clients.
Annapurna Finance was hosting four application workloads named E-FIMO, MSME LOS, MSME AUDIT and HRONE with an existing Cloud Services Provider named CtrlS. The E-FIMO and MSME LOS application workloads were used for executing loan origination and loan management tasks for servicing the company’s loan clients. The MSME AUDIT application workload was used by the company for handling internal auditing activities, and the HRONE application workload was a Human Resources Management application used by the company for servicing its internal employees.

• Annapurna was encountering problems with uptime with their current Cloud Services Provider. The services offered were frequently inaccessible to end users due to frequent network and infrastructure problems at the datacenter of the service provider. This was adversely affecting their reputation and causing a decrease in revenue.

• It was noticed that the MSME LOS application relied on a monolithic architecture. However, it was noted that adopting a microservices architecture would significantly enhance the application’s performance and scalability. Therefore, modernizing both the application and infrastructure would enable the organization to keep up with the
expanding customer base across Pan India.

• The customer did not employ any CICD/DevOps tools to roll out modifications to the current application. Consequently, each deployment required some downtime. As any period of downtime could adversely affect their revenue, customer loyalty, and overall business, they could not afford to take any risks.

• The organization aimed to move their 65 virtual machines distributed across 15 application workloads based at the CtrlS Datacenter. However, they lacked the expertise required and were searching for a partner who had ample experience in conducting large-scale migrations. The partner would aid in assessing their readiness for Cloud migration, devising a financial justification, determining the associated costs, creating a comprehensive Cloud migration plan, and eventually shifting the applications to the AWS Cloud.

1. Workmates wanted to holistically support the customer to meet both their business and technical objectives as part of this program. A detailed
discussion was done with Annapurna Finance’s technical and management teams to understand their existing application infrastructure and the pain
points associated with them. Inputs were taken from them to understand their expectations from the Workmates Team and the AWS Cloud infrastructure.

2. To better understand the business and the current capability gaps, a migration readiness assessment was performed. It was performed to understand business, people, technology, IT process are ready to adopt cloud journey. The AWS MRA Tool was used on the gathered inputs to generate relevant reports like the Heatmap and Radar which helped in understanding the existing strengths and weaknesses of the existing IT process, People, and Technology for the forward journey to the AWS Cloud. The MRA Report helped in designing a solution plan for a smooth journey to the AWS Cloud by building upon the current weaknesses.

3. The AWS Cloudamize Tool was used with the customer’s consent to give a detailed utilization report of their existing infrastructure. The report was
analysed, and right-sizing was performed for all servers. The customer was presented with a detailed report highlighting the 3-year cost and performance benefits of migrating their current application infrastructures to the AWS Cloud with right-sized server instances.

4. The dependencies for the existing application infrastructure were determined and the applications were migrated to the AWS Cloud in various
phases using the Cloud Endure tool following AWS best practices.

5. For migrating the customer’s MySQL and MSSQL databases, the AWS Database Migration Service (DMS) was used, adhering to all AWS specified
best practices.

6. All the Application and Database servers were migrated to private subnets. The public subnets were provisioned with Application Lod Balancers to provide secure access to the applications by external Internet users.

7. AWS enterprise tool CloudWatch was implemented for monitoring server resources and trigger alarms in case of any service outage issues.

8. AWS S3 with an object-based storage was provisioned as a native backup site to accumulate the data backups of the database servers daily. To protect unwanted access to backups, the S3 buckets were encrypted with SSE-S3.

9. AMIs of the server instances and EBS snapshots of the server hard disks were scheduled to be regularly taken to restore the server instances in the rare case of any service outage.

10. The servers were configured with the latest updated versions of Windows and Linux Server OS according to customer requirements. The root EBS
volumes for all servers were kept only for the OS. An additional EBS volume was used for data related to the applications and databases.

11. Periodic patching activities for the servers were configured through AWS SSM Patch Manager.

12. The MSME LOS application workload was modernized from a monolithic to a microservices based architecture and application code changes were automated by means of CI/CD pipelines implemented by a Jenkins Server.

1. Using IAM, users and groups were restricted to access specific AWS resources only as per the customer’s requirement.

2. AWS Multi-Factor Authentication was enabled for privileged accounts.

3. Quarterly Patch Management and Patch Automations was carried out using AWS SSM. During patching activities, all the security patches and OS critical patches were applied.

4. Deep visibility into API calls was made possible through AWS CloudTrail, including who, what, and from where calls were made. All user related activities were tracked and logged.

5. All the SSH ports were bound with OpenVPN server and default ports numbers were
customized.

6. The DB servers were made accessible only through the Application containers and through the VPN. All servers were hosted on private subnets.

7. For Configuration Management and Policy as a Code, AWS Config was used, which would help detect any configurations drifting within the AWS Account.

8. Trusted Advisor Checks were carried out every week to ensure that all the security criteria are met properly.

9. All the CloudTrail and CloudWatch logs were sent to AWS Guard Duty for threat detection and for identifying malicious activities in the account.

10. AWS Secrets Manager was used to store the DB credentials encrypted using KMS.