How the cloud revolutionized software development, became unnecessarily complicated, and why developers are looking for simpler solutions.
The golden age of AWS
There was a time when AWS was the obvious choice.
Launching a startup? AWS. Building a scalable backend? AWS. Running enterprise infrastructure? AWS.
When Amazon launched S3 and EC2 in 2006, it fundamentally changed software development. Companies no longer needed to purchase physical servers or build data centers before launching products. Developers could rent computing power on demand and scale as their businesses grew.
AWS made infrastructure accessible to everyone. It was a revolution.
But over time, something changed.
When simplicity became a nightmare
AWS kept expanding. Every problem seemed to get another service, another configuration option, and another layer of abstraction.
Need to deploy an application? Choose between EC2, ECS, EKS, Fargate, App Runner, and Lambda.
Need a database? There are multiple options, each with different capabilities and trade-offs.
Need networking, permissions, monitoring, and security? Prepare to learn IAM policies, VPCs, subnets, security groups, load balancers, CloudWatch, and more.
These services aren't identical, but their capabilities sometimes overlap, making the right choice surprisingly difficult.
And here's the irony: the cloud was supposed to make infrastructure easier, yet developers can spend days configuring infrastructure before delivering a single product feature.
For large enterprises with dedicated DevOps teams, this flexibility can be valuable. For a solo developer building a small SaaS, it can be complete overkill.
Sometimes all you need is a server, PostgreSQL, Docker, backups, and automated deployments.
Why should that require an infrastructure engineering project?
Developers are pushing back
This frustration isn't merely theoretical.
In public developer discussions on Hacker News, engineers have described startups spending disproportionate effort managing complicated AWS architectures instead of building their products. Others have complained about IAM configuration, forgotten resources, and the difficulty of extracting useful information from CloudWatch.
Meanwhile, 37signals, the company behind Basecamp and HEY, completed a migration of its remaining legacy applications away from cloud infrastructure in 2023.
Its founder, David Heinemeier Hansson, announced the move with the words:
«"We're out."»
The company cited potential cost savings and performance benefits from running those workloads on its own hardware.
Of course, one company's experience doesn't prove that everyone should leave AWS. But it demonstrates an important point: using a hyperscaler isn't the only legitimate way to run production software.
The rise of cloud-agnostic DevOps
The alternative isn't necessarily replacing AWS with Google Cloud and repeating the same architecture.
It's choosing technologies that preserve flexibility and avoiding unnecessary dependence on any single provider.
Consider a practical stack:
- Docker for packaging applications.
- PostgreSQL for relational data.
- GitHub Actions for CI/CD.
- Terraform or OpenTofu for infrastructure automation when needed.
- Standard APIs and portable application configurations.
A Dockerized NestJS application can run on multiple hosting platforms without rewriting its business logic.
That's the idea behind cloud-agnostic engineering: choose infrastructure based on actual requirements, not brand loyalty.
But don't turn portability into another over-engineered project. You don't need Kubernetes or elaborate abstraction layers for every application.
Alternatives worth considering
If you're looking for simpler infrastructure, several options are worth exploring.
DigitalOcean offers a straightforward cloud experience with virtual machines, managed databases, and application hosting. It's a practical choice for conventional web applications and APIs.
Hetzner provides affordable servers, making it attractive for developers who want to run Docker containers and manage their own infrastructure without the cost and complexity of a large cloud ecosystem.
Render simplifies deploying applications, background workers, and databases. It's useful when you want to focus on your code instead of configuring infrastructure.
Railway provides a developer-friendly way to deploy APIs, databases, and background services, particularly for prototypes and early-stage SaaS products.
Google Cloud remains a powerful option for applications that need managed infrastructure, Kubernetes, analytics, and enterprise-scale capabilities. However, switching to another hyperscaler won't automatically solve infrastructure complexity.
The right choice depends on your needs. VPS providers offer more control but require more maintenance. Managed platforms reduce operational work but may introduce platform-specific limitations.
You don't need the biggest platform. You need the right one.
Is AWS actually ending?
No. AWS remains a major cloud platform, and many businesses benefit enormously from its ecosystem.
What's changing is the assumption that AWS must be the default choice for every project.
Developers increasingly have alternatives that let them deploy software without assembling and managing a huge collection of infrastructure services.
A small SaaS doesn't need the same architecture as a global financial platform. A startup doesn't automatically need Kubernetes. And a complicated architecture isn't necessarily a better one.
The future of DevOps isn't about using more infrastructure. It's about delivering reliable software with less unnecessary complexity.
AWS helped create the cloud revolution. But developers don't owe any platform their loyalty.
Choose the simplest architecture that meets your requirements, keep your options open where it makes sense, and spend more time building products than managing infrastructure.
What about you? Are you sticking with AWS, moving to another provider, or choosing simpler infrastructure from the beginning?
Top comments (0)