Learn practical strategies to architecting your web application so it can pivot between providers, scale effectively, and maintain high performance and reliability. Discover how to future-proof your app and avoid the pitfalls of vendor lock-in. Future you, and your wallet, will thank you!
I created my first website in 1997. It ran on a Windows NT computer that sat in the back room of the local cybercafe, and it was so exciting. Something I wrote was on the internet. On my domain. It wasn’t on Geocities! (If you know, you know…)
You know what’s more exciting, though? Working on a web application today, and having it hosted on someone else’s computer within minutes. No server maintenance, no FTPing files, no hardware upgrades. Just one command line instruction or a git commit and my changes are live, often in less than a minute.
For many of us, this situation is quite perfect and will probably not change for a while. It’s up, it’s tested, and failed builds won’t bring your website down.
But sometimes, something happens that you might not be expecting. And for that eventuality, you might want to consider how to make your web applications truly portable.
Perhaps you’re here because you read that an empty S3 bucket racked up a $1300 bill, or that Netlify sent a $104K bill for a simple static site. There are plenty more horror stories like this at ServerlessHorrors.
Surprise bills can bring down websites, and it doesn’t only affect those on free-tier hosting that go viral or suffer a DDoS attack. Some providers have implemented or improved their budget controls, and while it’s not unheard of for these bills to be waived in some situations, you can’t rely on that.
Unsophisticated attacks are generally automatically mitigated by the platform e.g. Vercel has DDoS protection built in, as does AWS, and they also provide more advanced protections e.g. Vercel WAF or AWS Shield.
Some attacks are more sophisticated though, and look like normal traffic to the security systems built into your cloud platform. But for your specific app, these attacks are actually trying to find ways to rack up your AI token bill, abuse your checkout to test fraudulent credit cards, or scrape all your content. Or perhaps a legitimate paying customer making lots of API requests you actually really want to prioritize over a free user who is abusing their access?
Arcjet’s shield can detect suspicious activity, and for legitimate users you can add on our rate-limiting functionality.
import arcjet, { shield, fixedWindow } from "@arcjet/...";
const aj = arcjet({
key: env.ARCJET_KEY, // Get your site key from https://app.arcjet.com
rules: [
shield({
mode: "LIVE",
}),
fixedWindow({
mode: "LIVE",
max: 30,
window: "1m",
})
],
});
export async function handler(req) {
const decision = await aj.protect(req);
if (decision.isDenied()) {
// Return a 429 (rate-limit) or 503 (service unavailable) error
}
// Your business logic here
}While using a product like Arcjet will help mitigate the surprise bill scenario, there are additional strategies to consider before cutting off legitimate access to save on cost.
Minimize Bandwidth Usage
Managing Bandwidth Costs
I love modern hosting platforms for their developer experience. But if hosting large files with them exceeds your data allowance, consider hosting them elsewhere.
In some cases, like in the recent case where Cloudflare took down a website after asking for $120k within 24 hours, customers can have their account suspended or even terminated with no recourse. Whether you’ve been serving too much non-HTML content through a CDN, or have exceeded fair-use policies in an “unlimited bandwidth” plan, this could even happen without notice.
In this case, your options are severely limited. You can talk to the provider and work out how to resolve the issue, or perhaps you might choose to redeploy that service with another provider.
In the event that you need to relocate your web application elsewhere in a hurry, it’s worth expanding your architectural design decisions to work with multiple cloud computing services, rather than being designed to use platform-specific functionality.
Many platforms offer something extra; something useful that could make your life easier. Perhaps it’s registering your domain with your chosen CDN, or making use of image optimization tools built into your hosting platform provider.
The problem with these, from the perspective of a multi-cloud architecture, is that you are creating indirect dependencies on certain vendors that will hinder your ability to pivot quickly in the future. Your website will run perfectly fine on your current provider, but when you move it elsewhere, a whole load of functionality breaks.
The platform-provided tools are simply APIs that take an asset source, some constraints, and return the new asset. There’s no reason you can’t use another provider for this. Cloudinary is the first that comes to mind, but this is by no means a recommendation or endorsement. Find the right tool at the price point you are comfortable with to manage your visual assets.
Authentication is offered as an add-on service to a number of products, but really should be considered a first-class citizen of your application. Modern identity providers like Clerk offer additional features, like the ability to store arbitrary metadata against a user, while Microsoft Entra ID (formerly Azure Active Directory) is more straightforward and comes with a lower price tag. If you’re building your app in a JavaScript framework, you could also look at Auth.js.
In any case, selecting an identity provider that doesn’t require you to be hosting in a particular location makes it much easier for you to scale your application to other platforms without a lot of rework. Consider, also, the ease of switching identity providers – which features of the current provider are you using that you would have to redesign if you switched to a provider with different features?
Most modern hosting platforms include some level of network-layer protection against automated bots, suspicious activity, and DDoS attacks, but they’re rarely configurable and don’t run with the context of your application or your users. They also don’t run in your development environment, and might behave differently in staging, making it difficult to test your security measures.
By integrating Arcjet into your web application, you gain the ability to customize behavior for logged-out users and differentiate between various roles within the set of logged-in users. Arcjet's security features can be thoroughly tested in your development environment before deployment, ensuring consistency across all stages. More importantly, Arcjet provides this functionality independent of your hosting provider, making it easier to scale, add redundancy, or move your site as needed.
Register your domain with a registrar that is unconnected to any of your services, and then use their DNS services, or a service like Amazon Route 53 or DNSimple. The risks are low, but imagine if one of your hosting-related providers (hosting, CDN, email, etc.) suspends your account, and you’ve also registered your domain with them. You might have the most portable web application in the world, but there’s no use in being able to deploy it elsewhere if you can’t update your domain’s DNS records.
Designing for multi-cloud from the start enhances the flexibility, cost-effectiveness, and resilience of your web application. By leveraging multiple cloud providers, you can mitigate surprise bills and prevent account suspensions.
Implement robust rate-limiting to protect against abuse. Optimize and manage large files across different providers to keep bandwidth costs under control. To avoid vendor lock-in, use independent services tailored to each specific need, such as image optimization and authentication. This strategy allows your application to pivot easily between providers, scale efficiently, and maintain robust performance and reliability over time.
How we utilize AWS Route53, anycast, and multi-cloud to minimize latency and enhance performance for both servers and human users.
Fly automatically builds and deploys your containerized app globally, but you still need to handle the application security.
Environment variables seem convenient for secrets management, but they're a target for attacker lateral movement. Learn why they're risky and how to better store your secrets safely.
Get the full posts by email every week.