Athena Automation on AWS

ABOUT ATHENA
Athena is into the cab aggregation business. It took over a company called Flywheel and was now keen on further expansion across the USA.



THE CHALLENGE

Athena LLC is into cab aggregation and facing the challenge of scaling in and out during peak hours and weekends when demand for a cab is more than the regular hours.

The whole CI/CD process was manual along with infrastructure provisioning.

They were keen on having a full-fledged automated process to run the whole cycle of integration, deployment, testing etc. And during scale things should be automatically handled. But since there dev team was busy with feature requests and bug fixes there was no proper attention given on the automation and deployment initiatives. They also wanted help to make sure that customer data is protected across the application with proper backup and restore policy.



DEPLOYMENT LAPSES

The whole CI/CD process was manual along with infrastructure provisioning. It took a lot of time to provision infra with various dependencies on software versions. Also due to the complexity of business logic, manual deployment consumed a lot of time with a high risk of human errors.



PROPOSED ARCHITECTURE



INSIGHT ACTION

Techpartner team provided cloud consulting service and did a full-stack assessment of the existing application and the deployment strategy. We helped them to restructure the stack into a secure environment and limiting public access for load balancers only. Configured application load balancer to reduce overheads of having multiple ELBs wherever feasible. This helped them to reduce cost.

Techpartner worked with dev team to make sure that application is horizontally scalable to handle the load during peaky traffic.

Manual deployment was replaced by writing the Jenkinjobs, Config management and provisioning has been taken care by writing the Chef recipes. Custom monitoring tools are configured to track the actual progress of ride using Grafana and Nagios.

Cache has been incorporated between DB and Application to get the recent coordinates when the ride is in progress which in term reduced the load on the DB by 60%.

Data in transit and data at rest is encrypted as per the government norms with encrypted volumes in place.



SECURITY BEST PRACTICES

We designed the AWS architecture and implemented best security practices as per the AWS standards

● New 3-Tier VPC. (Public,Private & DB Subnet) with Separation of Staging and Testing environment

● IAM Role to the instance for S3 access

● IAM User for AWS Console access with MFA enabled with restricted policy access

● Password policy across entire Infra (Web, APP & DB) as well as in IAM

● Application changes were made to point local DB IP

● Only required ports are open for public access



DEPLOYMENT AUTOMATION
Deployment is automated for STAGING and PRODUCTION environment. This has been achieved by configuring Automation tools like Ansible & Jenkins. Deployment automation will remove instances from load balancer before deploying the releases and once the deployment is tested and verified using automated test cases, it will be added back to load balancer for serving the traffic.

Also, automation was done at the infrastructure level to automate launching of pre-baked instances, deploying the latest code on the instance and adding to load balancer thus enabling automated scaling.



THE BENEFITS
● Auto scaling Architecture: With this architecture the client able to serve their client with improved response time which in turns help to acquire more clients.

● Performance: As the application is configured in the Auto Scaling performance of the website improved with the good Response time.

● Automation: Automation reduced the manual deployment time and no more downtime on production due to this. The impact of this was also “zero” human error during deployment process

● Innovation: Team was able to concentrate more on Development than the production issues due to custom Deployment jobs for developers.



AWS STACK
For the success of project Techpartner used below AWS Services

● Amazon EC2 was used for computing with a combination of on demand and reserved instance. Instance were pre-backed to spin up when required

● Amazon Route 53 was used for both public and private zone. Records in private zones were used for internal communication between applications

● Amazon S3 was used to store backups, storing kinesis stream data and for uploading regulators data

● AWS NAT Gateway Service was used to provide the Internet to systems in private subnet during patch management

● AWS CloudWatch was used to monitor to the instance performance

● AWS CloudTrail was used to keep track of the activity across the AWS environment

● AWS Trusted Advisor was used for the recommendation of security groups and other security-related recommendations

● AWS Inspector was used to check application security and OS security and apply fixes as recommended

● AWS Config was used to track changes for AWS resources and also to alert with resources that are not a complaint as per defined rules

● AWS Identity and Access Management(IAM) was used to provide AWS resources access as per the company’s policy. Also wherever possible IAM roles were used to provide access to AWS resources as per IAM’s best practices

● AWS Lambda is used to take automated AMI backup and delete them after X number of days



For more, visit www.techpartner.in or contact us at info@techpartner.in.