Key takeaways
- Start with managed services; operate less, deliver more.
- Separate environments and keep databases off the public internet.
- Define infrastructure as code so it can be reviewed and rebuilt.
- Watch cost from the first month, not after the first surprise bill.
You don't need a complex cloud setup to run a reliable business application. A practical baseline architecture — and the signals that tell you when to go further.
Start with managed services
For most business applications, the best cloud architecture is the one with the least to operate. Managed databases, managed container platforms and object storage remove whole categories of maintenance work — patching, replication, backups — so a small team can focus on the product.
Choose the provider that fits your team, your customers and your existing contracts. AWS, Azure and Google Cloud all offer the building blocks a typical web platform needs.
A baseline that works for most applications
A dependable starting point for a web application or SaaS product usually includes the following.
- Separate accounts or projects for staging and production.
- A private network with the database unreachable from the internet.
- Stateless application containers behind a load balancer.
- A managed relational database with automated backups.
- Object storage and a CDN for files and static assets.
- Centralised logging, metrics and alerting.
Infrastructure as code
Clicking resources together in a console works once. Defining them in code — with Terraform, for example — means environments can be reviewed like any other change, recreated after a mistake and kept identical between staging and production.
Manage cost from the start
Cloud bills grow quietly: idle environments, oversized databases, logs kept forever. Tag resources by environment and purpose, set budget alerts, and review usage monthly. Right-sizing and scheduling non-production environments are usually the quickest savings.
When to go further
Kubernetes, multi-region deployments and service meshes solve real problems, but they also add operational cost. Adopt them when a specific signal appears, not because they are fashionable.
- Many independently deployed services that need common orchestration.
- Customers or regulation requiring data in specific regions.
- Availability targets that one region cannot meet.
- Traffic patterns that managed platforms can no longer absorb economically.
Enjoyed this? Get the next one by email.