01 Background
The client
The client sells smart products with an NFC chip built into them, a ring for example. Tap a phone against it and the phone opens a web page showing whatever the owner has saved there: a photo, a video, or a voice recording.
Simple idea. Demanding to host. Almost everything the platform stores and serves is video and audio, the heaviest files on the internet.
- Sector
- Consumer NFC products
- Workload
- Video and audio
- Stage
- Partly live
- Engagement
- 4 days
Client name withheld under NDA
02 Diagnosis
The problem
The app worked. The bill was the problem. It cost about as much to run as a platform with a large, active user base, except the user base was not there yet.
The build had been done at speed to get the product in front of people. That is a reasonable priority early on, and it leaves decisions behind that get expensive once they settle in. Our audit found three that mattered:
-
Everything on one provider, billed three ways
The server, the file storage and the data transfer were each charged separately by the same vendor, with no part of the setup placed where it was cheapest to run.
-
The app could not move
It was written for Amazon’s x86 servers with S3 as the only place files could live. Both were baked into the code, so the client was locked in whether the pricing suited them or not.
-
Video competed with the app
Media was streamed from the same server that ran the application, so both fought for the same bandwidth. Uploads were slow and playback buffered under load.
The audit also turned up passwords and access keys written directly into the code, file locations hardcoded to one web address, and a 214 MB installer file committed into the repository, where it served no purpose at all.
Moving everything to a cheaper provider would have lowered the bill for a while. It would not have fixed one of those. So we treated it as an architecture problem, not a shopping problem.
03 Execution
Our solution
We split the work across two cloud providers and gave each one the job it is genuinely good at.
-
Made the app portable first
The app now runs on ARM processors as well as x86, and the storage layer works with three options behind one setting: local disk, Amazon S3, or Oracle object storage. Oracle’s service speaks the same language as S3, so one piece of code covers all three. This had to come first, because it is what made the next step possible.
-
Moved the app to free compute
No longer tied to Amazon’s hardware, it moved to an Oracle Cloud ARM server. Oracle’s free tier gives four processor cores and 24 GB of memory at no recurring cost, more capacity than the client had been paying for. Server cost went to zero.
-
Moved media to storage built for it
All media moved to AWS S3 and is delivered directly to users, so the app server never touches a video. Uploads sped up and the buffering stopped. Because of the refactor, that choice is not permanent: switching providers means copying the files and changing one line of configuration.
-
Secured and tuned the server
Remote access and firewall locked down, automatic blocking of repeated login attempts, automatic security updates, self-renewing HTTPS, every password and key moved out of the code, and the app server, database and web server tuned to use the hardware fully.
04 Duration
Timeline
05 Stack
Tech stack
- Oracle Cloud (ARM64)
- Ubuntu
- Django
- Gunicorn
- Apache2
- PostgreSQL
- AWS S3
- Let’s Encrypt
06 Outcome
The outcome
| Criteria |
// After
BPDoxS
|
// Before Original setup |
|---|---|---|
| Monthly hosting cost | Under $120, over 90% lower |
Around $1,200 every month |
| Server cost | $0 on a free tier that fits the workload |
Charged by the hour, always running |
| Video playback | Served straight from storage, never touches the app server |
Buffering under load, competing for bandwidth |
| Supported servers | ARM or x86, on any provider |
Amazon x86 only, fixed in code |
| Storage options | Local disk, Amazon S3 or Oracle |
Amazon S3 only |
| Changing provider | One line of configuration |
Needed a developer and code changes |
| Keys in code | Removed and stored separately |
Passwords and access keys committed |
Over 90% cheaper in four days, and faster than it was before.