Cloud computing applications that earn their place: APIs, real-time workflows, AI agent runtimes, data pipelines, and event-driven services. The categories where the cloud gives you a real advantage over self-hosted or on-prem.
Table of contents
- APIs
- Real-time workflows
- AI agent runtimes
- Data pipelines
- Static sites with dynamic features
- IoT backends
- The architecture patterns in detail
- The selection criteria
- FAQ
APIs
The most common cloud application. A REST or GraphQL API that serves data to web and mobile clients.
Why the cloud wins: managed databases (no DBA needed), managed TLS (no certificate renewal), managed scaling (no capacity planning), managed observability (no Prometheus to set up).
The right architecture: API gateway or reverse proxy in front, stateless application servers behind, managed Postgres for state, object storage for blobs. The team that uses this pattern ships fast.
Real-time workflows
The right application for event-driven business processes. Order fulfillment, payment processing, user onboarding, notifications.
Why the cloud wins: managed queues (SQS, Pub/Sub), managed functions (Lambda, Cloud Functions), managed databases with strong consistency. The team that builds on these primitives ships workflows in days.
The right architecture: event source (webhook, message) -> queue -> worker -> database. The team that uses polling loops instead is missing the point.
AI agent runtimes
The right application for an agent that needs persistent state, scoped permissions, and observability. A chatbot is not an agent runtime; an agent runtime is the infrastructure an agent needs to do real work.
Why the cloud wins: managed databases for memory, managed secrets for credentials, managed functions for execution, managed observability for debugging. The team that builds agent runtimes in the cloud has the right architecture.
The right architecture: agent -> private runtime -> vector database (memory) -> Postgres (state) -> external APIs (tools).
Data pipelines
The right application for moving data between systems. ETL, CDC, streaming, batch.
Why the cloud wins: managed streaming (Kafka, Kinesis, Pub/Sub), managed data warehouse (Snowflake, BigQuery, Redshift), managed orchestration (Airflow, Dagster, Prefect).
The right architecture: source -> queue -> worker -> warehouse. The team that uses this pattern has clean, observable pipelines.
Static sites with dynamic features
The right application for content-heavy sites with light interactivity. Marketing sites, documentation, blogs, landing pages.
Why the cloud wins: managed static hosting (Cloudflare Pages, Vercel, Netlify, S3 + CloudFront), managed serverless functions for the dynamic bits. The team that builds on this pattern ships fast and scales infinitely.
The right architecture: static site on CDN, serverless functions for forms and auth, managed database for state.
IoT backends
The right application for fleets of connected devices. Sensor data ingestion, command and control, fleet management.
Why the cloud wins: managed MQTT brokers (AWS IoT Core, Azure IoT Hub), managed time-series databases (InfluxDB Cloud, Timescale Cloud), managed edge integration.
The right architecture: device -> MQTT broker -> stream processor -> time-series database + command queue. The team that builds IoT backends without these primitives is reinventing the wheel.
The architecture patterns in detail
A deeper look at each architecture pattern:
Three-tier web app. Web tier (static frontend or SSR), API tier (business logic), database tier (state). The classic architecture. The right choice for traditional web apps with user accounts and CRUD operations.
Jamstack. Static frontend (pre-rendered HTML/CSS/JS), API tier (serverless functions), database tier (managed database). The right choice for content-heavy sites with light interactivity.
Event-driven. Event sources (S3, SQS, Kafka), event router (EventBridge, Pub/Sub), event handlers (Lambda, Cloud Functions), state (DynamoDB, Firestore). The right choice for workflows and async processing.
Microservices. Multiple small services, each with its own database, communicating via APIs or message queues. The right choice for large, complex apps with multiple teams.
Serverless-first. All compute runs as Lambda/Cloud Functions. The right choice for spiky or unpredictable workloads.
The selection criteria
The right way to pick an architecture:
Team size. 1-2 engineers: monolith or Jamstack. 5-10 engineers: monolith or modular monolith. 20+ engineers: microservices or modular monolith with service extraction.
Traffic pattern. Steady traffic: traditional three-tier or monolith. Spiky traffic: serverless or autoscaling container-based.
Team experience. Strong DevOps: Kubernetes or self-hosted. Weak DevOps: managed PaaS or serverless.
Compliance. Strict compliance: self-hosted on dedicated infrastructure. Loose compliance: managed services.
The team that picks the architecture based on these criteria ships faster than the team that picks based on fashion or vendor preference.
FAQ
What’s the best cloud application to build first?
An API. APIs are the most common cloud application, the tooling is mature, and the deployment path is well-understood. The team that starts with an API learns the cloud primitives before tackling agent runtimes or IoT.
Do I need Kubernetes to build cloud apps?
No. Most cloud apps don’t need Kubernetes. The team that uses a managed PaaS (Heroku, Render, RunxBuild) skips Kubernetes entirely. The team that uses Kubernetes adds operational overhead that isn’t justified for most apps.
What’s the difference between a cloud app and a web app?
A web app runs in the user’s browser. A cloud app runs on cloud infrastructure. The team that builds a web app usually builds a cloud app to serve it. The two are complementary.
Should I use serverless or containers?
Serverless for spiky or unpredictable workloads, or for small services. Containers for steady-state workloads that need consistent performance. The team that uses both has the right architecture.
What’s the simplest cloud architecture?
Static site on a CDN (Cloudflare Pages, S3+CloudFront, Vercel, Netlify). No backend, no database, no compute. The team that uses this for landing pages, documentation, and blogs has the simplest possible architecture.
When should I use microservices?
When the team is large enough to have multiple teams working on independent services. Most teams below 20 engineers should stick with a monolith or modular monolith. Microservices add operational overhead that isn’t justified for small teams.
Is serverless always cheaper?
Not always. The team that has steady-state high-traffic workloads may find serverless more expensive than reserved instances or committed-use discounts. The team that has spiky workloads almost always finds serverless cheaper.
If you are sizing the infrastructure for the kind of project this post covers, the RunxBuild hosting calculator is the right place to model the line items. The compute, the memory, the storage, the bandwidth, the database - each one is a separate number, and the team’s mental model for the platform is the sum of those numbers. The RunxBuild dashboard is where the team sees the actual usage in one place.
Useful related references: