AWS Fargate

Heroku is unable to handle payment issues arising due to Indian Reserve Bank's decision to stop recurring card payments. I am using the following Heroku services:

1. Web Dyno
2. Worker Dyno (Scheduler)
3. Cron To Go (Queue)
4. @{ClearDB}|tool:317| (MySQL)
5. Heroku Redis (Queue Driver)

I have to migrate my Apache/ PHP/ Laravel/ HTML/ CSS/ jQuery/ MySQL application hosted on Heroku to a new provider. My current options visible are:

1. @{AWS Fargate}|tool:7969|
2. AWS Beanstalk
3. Quovery
4. @{Microsoft Azure}|tool:213|
5. @{Laravel Vapor}|tool:12336|
6. @{Laravel Forge}|tool:1727|

Does anyone have any guidance on which of the above options (or any other option not identified above) is recommended for migrating away from Heroku? and why?

We build a Slack app using the Bolt framework from slack https://api.slack.com/tools/bolt, a Node.js express app. It allows us to easily implement some administration features so we can easily communicate with our backend services, and we don't have to develop any frontend app since Slack block kit will do this for us. It can act as a Chatbot or handle message actions and custom slack flows for our employees.

This app is deployed as a microservice on Amazon EC2 Container Service with AWS Fargate. It uses very little memory (and money) and can communicate easily with our backend services. Slack is connected to this app through a ALB ( AWS Elastic Load Balancing (ELB) )

AWS Fargate was a really pivotal decision for us, because it ensured the integrity of code running in production. That was a major requirement for the security and compliance audits (SOC II, etc).

Successfully completing those audits gave us access to new business partnerships, while on the engineering side Fargate reduced the work needed to maintain production apps.

We use AWS Fargate because we want to focus on our business and the value we give to our customers and not on infrastructure management, OS patching and agent updates. Fargate is a way for us to run containers in scale without worrying about the underlying fleet of instances or resource management(bin packing, idle instances. etc)

At Qrvey we moved from a SaaS application running in AWS to a deployed model where we would deploy the complete infrastructure and code to a customer's AWS account. This created a unique challenge as we were Cloud Native and hence were using a lot of AWS Services like Amazon DynamoDB, AWS Fargate , Amazon Elasticsearch Service, etc. We decided to first build AWS CloudFormation templates to convert all our infrastructure into code. Then created a AWS CloudFormation template that would first generate a AWS CodePipeline into a customer's AWS account. This pipeline would then deploy our Infrastructure AWS CloudFormation template and the code on that Infrastructure. This simplified and completely automated our upgrade process as well.