Exabytes Cloud vs Custom Server for Android APIs

Latency Maps: KL, Singapore, and FCM

Exabytes runs virtualized instances out of Cyberjaya and Singapore data centers. A `curl` from a Maxis 5G phone in Bangsar to an Exabytes Cyberjaya endpoint lands around 8–14ms RTT. The same request to an Exabytes Singapore POP adds another 22–30ms because of the international bridge—fine for REST, but noticeable when your Android client fires 200 sequential Retrofit calls during cold start.

A custom server placed in AIMS Cyberjaya, running nginx 1.26 with TLS 1.3 session tickets, trims that to 3–6ms local. But that edge disappears for your Indonesian install base. If your app’s user map stretches into Jakarta and Surabaya, the Singapore POP becomes the real bottleneck fix, and Exabytes routes there natively. Your custom box in Cyberjaya forces traffic through whichever international gateway your IP transit provider peels onto—usually Telia or PCCW—which adds jitter under load.

FCM notification delivery also follows network paths. Exabytes Cloud’s internal DNS and outbound mail relays are pre-warmed for Firebase endpoints, so registration token rotation and upstream messages don’t hang on MTU fragmentation issues. A custom server needs manual `ip6tables` tuning and TCP window scaling on its Unifi Business fiber to stop packet drops during push bursts at 5:30 PM commuter hours.

Ops Load: Exabytes Managed vs Self-Patched

Your Android API backend is probably Laravel, FastAPI, or Ktor. Exabytes Cloud gives you a managed hypervisor layer: they handle host patching, IPMI remote console, and off-site snapshots via their Enclave panel. You still manage nginx, PHP-FPM, uvicorn processes, and MariaDB. The `apt upgrade` cycle for Ubuntu 22.04 LTS security patches lands every Tuesday, and Exabytes pushes host-level firmware updates without rebooting your VM if it’s on KVM with live migration enabled.

Custom server ops is a different contract. You own hardware failures. That 1U Dell PowerEdge R450 with two NVMe drives in RAID10 requires physical presence at the colocation rack if disk replacement is needed—unless you paid AIMS for remote hands, which adds RM150 per touch. You handle `unattended-upgrades`, pfSense firewall filtering, and VLAN isolation yourself. A full 2-hour patching window weekly, plus monitoring via Grafana + Prometheus node exporters, is the real cost nobody prices.

The security equation shifts based on API exposure. Exabytes Cloud’s managed perimeter includes basic DDoS protection at their edge routers. Custom servers need your own fail2ban rules and a Cloudflare tunnel or a dedicated anti-DDoS provider if you’re re-selling API access to third-party Android apps.

Capacity Planning for Concurrent Android Clients

A typical Android API session opens an OkHttp connection pool of 5–10 sockets, with keep-alive headers held for 3 minutes. At 500 concurrent users, the backend sees roughly 2,500 requests/minute. Exabytes Cloud plans below 4 vCPU show CPU steal during peak hours because your VM shares physical cores with noisy neighbors on the same hypervisor. That causes GC pauses in a JVM-based Ktor gateway and stalls in Python’s asyncio event loop.

A custom server allocates dedicated physical cores, which eliminates CPU steal entirely. Use `pidstat` and `perf` to verify. For 95th percentile latency under this load, the custom box holds at 150ms from Android device to response, assuming your API has proper Redis caching for session tokens. Exabytes Cloud on the same plan runs 190–210ms under identical load because of virtualization overhead on packet interrupts.

Vertical scaling is where Exabytes wins. You resize a VM or enable auto-scaling nodes in their panel within 10 minutes. Custom server capacity means buying another chassis and negotiating colocation power allocation with AIMS—a 2–3 week procurement cycle, not minutes. If your Android app’s MAU spiked after a random MyKad-ID verification feature went viral, Exabytes absorbs that.

TCO Math: RM/Hour and Rebuild Cycles

Run the 36-month math. Exabytes Cloud mid-tier (4 vCPU, 8GB RAM, 80GB SSD) is around RM289/month—RM10,404 over three years, no hardware obsolescence risk. Every kernel upgrade is included.

Custom server: RM6,800 for a Dell R450 refurbed with 2x Xeon Silver, 64GB ECC, 2x 960GB NVMe. AIMS Cyberjaya colocation at 1U is RM420/month with 1Gbps unmetered bandwidth—RM15,120 over three years. Add RM180/year for AIMS remote hands and RM0 for hardware depreciation because you can sell it for RM1,800 at year three. Total net: roughly RM18,500.

Break-even lands at month 12. After that, custom is cheaper, but your time is now the sunk cost. If you’re a 2-person dev team in KL shipping an Android MVP, Exabytes Cloud’s panel automation frees the hours you’d otherwise spend in `screen` sessions running `debootstrap` rebuilds and firmware updates. If you’re running a production API with 100,000+ devices, custom wins—but only after you’ve hired someone for the ops work.

The Real Decision Trigger

Ask one concrete question: does your team hold a weekend-on-call rotation for infrastructure? If yes, Exabytes Cloud. Their Cyberjaya DC has redundant power and UPS backing, and their support ticket median response under SLA is 12 minutes during Malaysian business hours. Custom colo puts that on-call rotation inside your own premises, with no one but your phone to respond to an IPMI SDR warning at 3 AM.

For Android API work specifically, neither option is wrong technically—FCM, Retrofit, and protobuf run identically on both. The divergence is operational: storage replication, backup integrity testing, and how fast you can spin up a staging environment when a Play Store beta build hits a distributed tracing bug. Exabytes does that in one panel action. Custom requires your Ansible playbook to be genuinely idempotent, which maybe it is, or maybe it throws on the third re-run like last time.