A SaaS company migrated their monolithic application to AWS three years ago. Traffic has grown 8x since. Their cloud bill has grown 11x. Every Black Friday, they manually provision additional servers two weeks in advance and pray. Post-sale, those servers run at 12% utilisation for two months.

The problem isn't the cloud. The problem is that the application was built for a server — not for cloud. Moving it to cloud changed where it runs, not how it behaves.

What Cloud-Native Actually Means

Cloud-native is an architectural approach, not a hosting decision. It describes applications designed to exploit the specific capabilities of cloud infrastructure: elastic scaling, managed services, distributed state, and continuous deployment. A cloud-native application gets cheaper per unit as it scales. A cloud-hosted application gets more expensive.

The Four Pillars of Cloud-Native Architecture

Containerisation

Applications packaged in containers are portable, consistent, and fast to deploy. More importantly, containers are the unit of scaling — you scale the specific component under load, not the entire application. A spike in API traffic doesn't require scaling your database.

Microservices (where appropriate)

Not every application should be a microservices architecture — the operational overhead is real. But decomposing a monolith into independently deployable services creates crucial flexibility: teams can deploy their component without coordinating a full-application release, and problematic components can be replaced without touching the rest of the system.

Managed services

Cloud-native applications delegate undifferentiated infrastructure to managed services: managed databases, managed queues, managed caches, managed identity. Your team writes business logic, not infrastructure management code.

Infrastructure-as-code

Every environment — development, staging, production — is defined in code. Spinning up a new environment takes minutes, not weeks. Disaster recovery is tested regularly, not hoped for. Changes to infrastructure go through the same review process as application code.

When to Refactor vs When to Rehost

Not every application needs to be rewritten to be cloud-native. The decision depends on the trajectory: if an application will need to scale significantly, if deployment frequency is a competitive factor, or if the infrastructure cost is growing faster than the business, refactoring toward cloud-native architecture delivers compounding returns.

For stable, internal applications with predictable load, a well-managed rehost is often the right call — cheaper upfront and lower risk. The mistake is applying rehost thinking to applications that will need to scale.

We help clients make this distinction accurately, based on actual load data and growth trajectories — not instinct.