Hosting and cloud
Where the application actually runs.
Nothing matches that yet
Try a broader category, or add the product you were looking for.
Add a productWhat this shelf covers
Places to run an application: managed platforms that deploy from a repository, container services, virtual machines, and full cloud providers with several hundred services attached.
The right answer depends less on scale than on how much operational work you want to own. Every layer of control you take adds a duty that arrives at an inconvenient hour.
Databases have their own shelf in databases. Watching what happens once it is live belongs in monitoring.
Four levels of control
Managed platforms take code and run it. Deployments come from a repository, scaling is a setting, and most infrastructure decisions are made for you. They are the fastest way to production and the least flexible when something unusual is required.
Container services sit a step lower, running images you build with orchestration you configure. More work, more control, and a portable artifact that moves between providers.
Virtual machines give you an operating system and everything that comes with it, including patching, security and backups.
Full cloud providers offer all three plus a catalogue of managed services, at the price of complexity and a bill that requires attention.
The questions that decide performance
- Region choice, close to your users and to your database.
- Cold starts, on anything that scales to zero between requests.
- Persistent connections, which some serverless models handle badly.
- Build and deploy time, since a ten-minute deploy changes how often people ship.
- Static delivery, cached near visitors rather than served from the origin every time.
Distance between the application and its data is the most common self-inflicted problem. Fifty queries a page across a region boundary produces a slow site that no amount of front-end work can rescue.
Reliability, and what happens on a bad day
Uptime promises are worth reading rather than trusting. Most cover the provider’s own control plane and compensate with service credits, which is not what an outage costs you.
Ask about failure domains: whether your instances sit in one zone or several, what a redeploy does to live traffic, and whether rollback is a button or a rebuild. Ask how logs are retained and whether you can reach them when the dashboard is unavailable.
Then ask about the recovery you control. A provider outage is survivable if your data has a copy elsewhere and your deployment is reproducible. Neither is true by default.
Cost, and the lines that grow quietly
Compute is the number on the pricing page. The invoice is usually made of five things.
Egress is charged per gigabyte for data leaving the provider, and it accumulates fastest in video, downloads and traffic between regions. Storage grows and rarely shrinks. Managed services carry their own meters. Build minutes count on platforms that rebuild on every push. Support plans are extra almost everywhere above the basic tier.
Development and staging environments double much of this unless they are sized down or stopped overnight. Ask what the total looks like at three times current traffic, since that is the figure you will actually meet. The habit of burying such meters is covered in what pricing pages hide.
Portability, and how to keep it
Lock-in in this category is rarely dramatic. It accumulates one convenient service at a time.
Containers and standard runtimes travel. Proprietary functions, queues, identity services and databases do not, and each adoption raises the cost of leaving. That is a legitimate trade when the service saves real work, and a poor one when it saves an afternoon.
Keep infrastructure defined as files rather than as console clicks, and stand the whole thing up from scratch once. What you learn from that exercise is worth more than any comparison table.
Matching the platform to the application
A standard web application with a database is well served by a managed platform, and the time saved is worth the premium for almost any team without dedicated operations staff.
Background processing, queues and scheduled work change the picture, since serverless models handle long-running tasks badly and some platforms have no place to put them at all.
Anything with unusual requirements, whether that is specific hardware, sustained high traffic or strict data residency, tends to push towards raw cloud or dedicated machines.
Static sites belong at the cheap end and often cost nothing to serve properly.
Decide from the shape of the workload rather than from the size of the company. Small teams run demanding applications, and large ones frequently run simple ones.
Questions people ask
- What is the difference between a platform and raw cloud?
- A platform takes your code and runs it, deciding most of the infrastructure for you. Raw cloud gives you machines and networks to assemble yourself. The first trades control for time, the second trades time for control.
- Where should I host for the best speed?
- Close to your users and close to your database. Cross-region distance between the application and its data undoes most other optimisation, and a content network only helps with static files.
- How does egress pricing work?
- Data leaving the provider is charged per gigabyte, often more than storing it. Video, downloads and cross-region traffic are where it accumulates, and some providers waive it entirely, which is worth checking early.
- Do I need a content delivery network?
- For any site with a global audience, yes, and most platforms include one. It caches static files near visitors and does nothing for dynamic responses, which still come from the origin.
- How do I avoid lock-in?
- Keep the application portable and be deliberate about which managed services you adopt. Containers and standard runtimes move. Proprietary functions, queues and databases are what make a migration a rewrite.