When we start our journey in some startup then initially we don' take much care of Infra as getting initial Product ready for MVP is our priority
I have encountered many cased where clients are looking for MVP setup and in the initial stage we don't need to worry much about infra and complex architecture, These Apps can be just 2 Tier application without complex architecture
- initial stage we need MVP
- initial stage we don't need to worry about complex design and infra
- initial stage we need demo product ready
For all such use-case i always provided my inputs of having Heroku as Infra Provider where we don't need to do much configuration and management.
With Heroku, startup developers have access to a cloud-based platform-as-a-service (PaaS) to design, develop, deploy, and run applications. You don’t need to worry about servers, hardware, or infrastructure. With this fully managed platform you can concentrate on building an exceptional product. With seamless scalability and advanced features, Heroku supports your app success long term as your business grows.
In the Heroku paradigm, Heroku uses a system of managed containers called Dynos. This platform enables modern applications to run, deploy, and utilize integrated data services.
As a web application deployment model, Heroku supports several programming languages. Heroku has been in development since June 2007, when it was one of the first cloud platforms, and Ruby was the only programming language supported.
However, it now supports Java, Node.js, Scala, Clojure, Python, PHP, and Go. Therefore, Heroku offers an inexpensive way to scale applications, regardless of their language.
Heroku supports diverse solutions. Developers can also deploy apps written in any other language using custom buildpacks from Heroku. It is, therefore, a polyglot development platform, and it allows developers to create, run, and scale applications across different programming languages in a similar way.
Heroku Dynos Facilitate Easy Development and Improve Usability A Heroku application is typically bound to a domain name used to route HTTP requests to the appropriate container. Application containers are used to host Heroku applications. A container runs a service packaged as a small package. Containerized applications are running on reliable, managed runtime environments supported by smart containers. The Heroku platform deploys application containers across a “dyno grid.” This is a collection of servers, and Dynos are managed and operated by the Dyno manager.
Due to Heroku’s ability to manage and run applications, it’s not necessary to handle operating systems or other internal configuration features.
The app can be made to run in more dynos or on a different dyno depending on the type of dyno. Users can always expect faster performance when using an application that can scale quickly.
This study shows that almost 50% of growing startups started their business on Heroku and then migrated to a Cloud provider - especially AWS (Amazon Web Services). Let us unpack the three big reasons:
When startups grow, they all seek better control and ownership of their infrastructure, whether the servers we use or cloud hosting for our apps. Deploying apps on Heroku doesn't give you ownership and control of the infrastructure; and Heroku owns it, and users get access to it. The need to have more control
Here Heroku offers limited control and hampers control, and limits scalability. For example, in networking, the applications can only listen on a single port, and startup constraints of mandatory booting up in less than a minute, doing development under these constraints and limits controls and scaling-up opportunities.
Even though AWS is not known for being cheap, Heroku is up to 10x more expensive than AWS for the same use. The more you use it; the more your bills go up. Peace of mind at a price, but it's tough to scale with Heroku. Why should you consider Qovery to migrate from Heroku to AWS? Let’s talk through some of the benefits of using Qovery to migrate from Heroku to AWS:
You do not need cloud infrastructure expertise, and you can set up the infrastructure in just four simple steps (see our step-by-step guide here)
Get the Heroku-like experience with the flexibility you need— Qovery offers fully automated deployments to your AWS account. You get the same developer experience as Heroku (no DevOps knowledge required), but now you have full access to inspect and tweak anything without Heroku limiting you.
Deploy and scale effortlessly— Qovery utilizes a Kubernetes cluster behind the scenes (EKS). Qovery manages and scales services in your existing AWS account so you can focus on building products instead of managing its infrastructure.
We decide for migration is because of our services are not being consumed 24*7, with limited customers we just want serverless cost saving model and that becomes an important point for AWS Serverless Migration
aws serverless lambda and amazon serverless arora saves a lot for our infra billing
Simple architecture using AWS-CDK
We enjoyed building whole infra using AWS-CDK
- S3, cloudfront for FE applications
- lambda, api gateway, dynamo db, s3
- secret manager, sns, sqs, event bridge
- amazon arora serverless
- aws cdk to deploy application lambda using ci/cd
- lambda per microservice using nodejs nestjs (AWS SAM)
- Dynamo Tables with S3 and APIs written in Nest JS Node JS
i hope you enjoyed our migration journey