About Quickwork
Quickwork provides an all-in-one platform with the tools and services you need to build powerful & scalable integrations, serverless APIs, conversational experiences, and a lot more!
Quickwork supports all types of events used in automated workflows, such as real-time, polling, scheduled, and manual. This unique capability enables building a wide range of workflows across industry verticals.
THE CLIENT’S CHALLENGE
Quickwork wanted a solution which helps them make automation easy, affordable, accessible and compliant.
There aim to trigger the workflow in real-time as soon as the event occurs in the source application systems.This event type is suitable for conversational, IoT, financial, and other use cases that require instantaneous response
Since there is a case where millions of such events can occur it needed the infrastructure to support this. Also these events won’t be there in the system for more than 15 to 20 seconds. That means they only need the processing power for < 30 seconds when an event occurs. And whenever an event occurs there should not be more than 1 or 2 seconds of delay accepted to process the event.
On top of this complex solution the client was also looking for the affordability i.e. solution should not be a costly affair.
ARCHITECTURE
DEPLOYMENT AUTOMATION
The CI (continuous integration) process is managed using Jenkins. An image is pulled from docker repository, customized with application code and then pushed to Amazon Elastic Container Registry (Amazon ECR).
In the CD (continuous delivery) process, the image is pulled from Amazon ECR and applied in the respective Kubernetes namespace.
INSIGHT TO ACTION
The TECHPARTNER team worked with the Quickwork management team and tech leads to understand the project needs. Together we chalked down the plan and finalized the architecture. Our focus was to leverage AWS services and utilize the open source tools to achieve the required output.
To process millions of events which will be there in the system for < than 30 seconds there is no other service better than EKS. We use AWS EKS to support the scale and faster rollout. The architecture consisted of setting up auto-scaling nodegroups using a mix of on-demand and spot instances for better performance, scalability and cost optimization.
To save more cost we also migrated half of the infrastructure including more than 50% of Kuberneties Node and some part of Databases to newly available ARM (Graviton) Processors which make the entire solution affordable without any compromise to performance. Entire infrastructure is able to support 5000 API trasactions/second.
BENEFITS
- Scalable Architecture: With the scalable architecture Quickwork was able to serve the user with improved response time which in turns helped to acquire more users
- Performance: As the application and deployment is modular, the whole CI/CD process became easy and efficient
- Automation: Automation reduced the manual deployment time by 90% giving free hand to developer to concentrate on Innovation
- Cost Saving: With Scalable EKS architecture along with ARM (Graviton), the client was easily able to launch more than 2 Million of pods on the EKS cluster to execute the customer workflows in a day without any hiccups to support more than 5000 transactions/second and reduce cost 35% when compared to any regular EC2 instance.
AWS STACK
- AWS WAF: Since this is a consumer facing application, WAF is suggested for better security.
- AWS CloudFront: The frontend of the application is served via CloudFront for quicker response to customers and take advantage of CloudFront edge locations.
- Amazon Elastic Kubernetes Service (EKS): The EKS is used to host and deploy the application stack.
- AWS Application Load Balancer (ALB): The application is hosted on ECS. The ALB is used to load balance and expose the application to the internet. ACM is used to generate SSL certificates and applications are made to serve only SSL encrypted payload to end customers.
- AWS EC2 instances: A mix of on-demand and spot instances is used for hosting all the applications on ECS nodes. Node autoscaler and HPA (horizontal pod autoscaler) is used to scale in and scale out applications depending on end traffic load.
- AWS ElastiCache: ElastiCache Redis is used to store the session and transient data.
- AWS Lambda: Multiple Lambda jobs have been written in Node.js ver 14.x for application functionality
- AWS Managed Streaming for Apache Kafka (MSK): MSK is used to process streaming data and jobs.
- AWS Cloudwatch: AWS Cloudwatch is used for monitoring and alerting. Resource usage of the infrastructure is monitored using Cloudwatch dashboards. Whenever any critical threshold is breached (e.g. too many 5xx on ALB), an alert is sent out to the Operations and Engineering team for investigation. Billing alerts have also been set.
- AWS Route53: Route53 is being used for DNS. DNS zones are set for internal as well as public facing records.
- AWS S3: S3 is used for storing frontend application code and static assets (which are served by CloudFront eventually). S3 is also used to store backup data.
- AWS Lifecycle Manager: It is used to take instance’s image backup.
- AWS RDS: MySQL and Postgresql are used to store the transactional backed data.
- AWS Key Management Service (KMS): KMS is used to encrypt all data storage volumes using custom keys.
