Why Heroku and AWS have failed to serve modern developers?
By using Heroku, developers benefit from a great developer experience to deploy their apps; at the price of flexibility, control over the infrastructure (no fine-tuning for your DB), and going beyond what Heroku allows (static IPs and VPC for Enterprise plan only, no private subnet, only 2 regions,... ).
Wherewith AWS, you will benefit from the full flexibility, powerful infrastructure capabilities, and tons of great services; but at the price of dealing with all the over-complexity of their services. Have you ever tried to simply deploy a simple app? - you will need to set up a VPC, a load balancer, a security group, a container registry, etc... until you maybe succeed to deploy your app. Otherwise good luck!
At the same time, for years now, I am seeing a new generation of developers and CTOs emerging. Those people are building services that you use every day and want to keep focusing on what they are building without compromising on using the best services that service cloud providers like AWS can provide.
Over the past 12 months, I’ve talked with 350+ CTOs & Developers from the US, Europe, and Asia to better understand how do they work on Heroku and AWS and what they expected from them. In this article, I’ll share (i) the most common challenges this new generation faces, and (ii) what do they need.
The 3 main challenges modern developers are facing in 2022
I will describe each challenge scenario with a real quote from the CTOs and developers we met.
Challenge 1. As the company grows, developers move out from Heroku limitations to AWS but run into complexity
Initially, we were on Heroku and started to have some issues with the proximity of Heroku services (not available in the south Pacific). We had to switch to AWS to overcome these Heroku limitations but it is starting to require more and more DevOps resources to manage our infrastructure — Nishant, CTO of My Muscle Chef
We are in the process of moving most of our apps to microservices and this is something that Heroku handles rather poorly. Overcoming these challenges means moving to an IaaS such as AWS but it requires resources and too much time (and knowledge) to set up and maintain — Teodoro, CTO of Greener
We are on Heroku since the start, for its simplicity. But we started facing some performance and costs issues so we consider switching to AWS, but it requires a significant effort (including DevOps resources and time) — Tech Lead at Hosman
We were considering moving out Heroku to AWS and started using Fargate for app deployments but it remains too complex to manage — CEO of GoTab
Challenge 2. Keeping developers focused on “dev work”
We are micro services-oriented so we prioritize that architecture, but the hassle of managing infrastructure can be a lot. We don’t want to spend a lot of time on infrastructure but at the same time, we want to build in a way that will scale if it's a success — Kristof, Founder of Filerr
We needed better options for our budding business that can keep them in the cloud, allow us to scale and control costs, and still give them value by allowing our devs to strictly focus on dev. We are looking alternative to move our apps from Heroku to AWS — Luis, COO at Kauneonga
We are a brand new startup looking to finish developing our main features and deploy them before next week. We don't have DevOps/infra experts, and we don't have a lot of time to devote to these areas. We deployed the current version of our app on Heroku for the first time a few days ago, but we don't have much control over anything — Kevin, Head of Data Science at Finvault
We want our dev team to focus more on "dev" work rather than spending time trying to figure out AWS configs and how to set up different environments. We started to use Beanstalk but it remains still complex to manage and things are not working well (mainly the auto-scaling part) — Bodgan, CTO of Nifty Learning
Challenge 3. Keeping developers productive while the team is growing
Shortly after being acquired by a bigger company, our tech team grew x4 in 2 months. Now the team is bigger, we need to create new environments faster and easier — Alex, CTO of WeMoms
We are using ECS in AWS for our microservice orchestration. We would like to deploy the ECS tasks to enable PR preview for our microservices. Also, today we do PR preview for UI using Vercel but we have nothing on the backend side — Snehit, CTO of Bepoz
Maintaining our own full-stack preview environments is not worth the time for us. We are looking to find a DevOps solution like Vercel but hosted on our own Cloud and handles more than just frontend deployments. — Andreas, CTO of Flick
So, what do modern developers need in 2022?
Modern developers need to stay focused on what makes their products unique.
Modern developers do not need to leave AWS.
Modern developers need a better AWS developer experience.
Modern developers need to ship faster.
Modern developers need to understand their bills and pay the right price.
Modern developers need more control and transparency on their infrastructure.
Modern developers need to keep their data safe.
Modern developers need the simplicity of Heroku and the flexibility of AWS.
Are you a modern developer? Check out Qovery's DevOps Automation Tool now!
.svg)
.svg)
.svg)
Suggested articles
Scaling your deployments to zero is only half the battle. If your cluster autoscaler does not aggressively bin-pack and terminate the underlying worker nodes, you are still paying for idle metal. True environment sleeping requires tight integration between your ingress layer and your node provisioner to actually realize FinOps savings.
The biggest mistake enterprises make when evaluating Kubernetes management platforms is confusing infrastructure provisioning with Day-2 operations. Tools like Terraform or kOps are excellent for spinning up the underlying EC2 instances and networking, but they do absolutely nothing to prevent configuration drift, automate certificate rotation, or right-size your idle workloads once the cluster is actually running.
For years, Red Hat OpenShift has been the safe choice for heavily regulated, on-premise environments. It operates as a secure fortress. But in the public cloud, that fortress acts as an expensive prison. Paying proprietary per-core licensing fees on top of your standard AWS or GCP compute bill is a redundant "middleware tax." Escaping OpenShift requires decoupling your infrastructure from your developer experience by running standard, vanilla Kubernetes paired with an agentic control plane.
Agentic Kubernetes resource reclamation is the practice of using an autonomous control plane to continuously identify, suspend, and delete idle infrastructure across a multi-cloud Kubernetes fleet. It replaces manual cleanup and reactive autoscaling with intent-based policies that act on business state, eliminating the configuration drift and cloud waste typical of unmanaged fleets.
Kubernetes focuses on container orchestration, but the reality on the ground is far less forgiving. Provisioning a single cluster is a trivial Day-1 exercise. The true operational nightmare begins on Day 2. Teams that treat multi-cloud fleets like isolated pets inevitably face crushing YAML configuration drift, runaway AWS bills, and severe scaling bottlenecks.
Rancher solved the Day-1 problem of launching clusters across disparate bare-metal environments. But in 2026, launching clusters is no longer the bottleneck. The real failure point is Day-2: managing the operational chaos, security patching, and configuration drift on top of them. Rancher is a heavy, ops-focused fleet manager that completely ignores the application developer. If your goal is developer velocity and automated FinOps, you must graduate from basic fleet management to an intent-based Kubernetes Management Platform like Qovery.
The shift from AI copilots to autonomous agents is redefining infrastructure requirements. Discover how to build secure, stateful, and compliant Agentic AI systems using Kubernetes, sandboxing, and observability while meeting EU AI Act standards
.webp)