Why Build Your Own Database Middleware in the Multi‑Cloud Era?

Background

Lin Jing, a Java technology expert from the core infrastructure team at Lalamove, shares insights from the "Deeplus Live" session on building stable, highly available core infrastructure in multi‑cloud scenarios.

Why Build Your Own Middleware?

Many assume that cloud adoption eliminates the need for self‑built middleware, but the speaker argues the opposite: multi‑cloud environments increase the necessity for custom middleware to handle technical adaptation and maintain vendor neutrality.

Technical adaptation: Native and cloud environments differ, requiring middleware to bridge the gap for smooth migration.

Vendor neutrality: Cloud providers offer non‑standard services; without middleware, enterprises become locked into specific platforms.

Challenges in Multi‑Cloud

Rapid business growth leads to database bottlenecks, increasing the number of databases, multi‑language heterogeneity, and multi‑cloud deployments.

RDS products vary across clouds.

Linear scaling solutions cannot span multiple clouds.

Frequent DB sharding and merging pose high risk.

Product changes are costly and slow.

Traditional migration involves four steps: sync data to a new DB, pause business, restart services with new connection strings, and resume operations. This process is lengthy and risky, highlighting the need for dynamic connection management.

Building Database Middleware for Multi‑Cloud

Self‑built middleware decouples business services from the DB layer, providing a unified connection string and handling adaptation, scalability, and high availability.

The architecture enables flexible DB product selection and cross‑cloud designs.

Core Features

Template‑based sharding and read/write separation: Provides scalable MySQL clusters with automatic sharding logic, hiding complexity from developers and DBAs.

Multi‑tenant support: Pools resources, isolates configurations and execution, improving cost efficiency.

SQL tracing and governance: Offers fault protection, emergency handling, and detailed monitoring to ensure DB health across clouds.

Key Technical Indicators

Linear scaling limit: single‑node capacity ×1024.

Multi‑tenant limit: up to 10 000 logical clusters per cluster.

DB migration impact: seconds‑level interruption.

Latency: 99.999% of requests under 10 ms.

Availability: 99.999% service uptime.

Cost: less than 5 % of comparable RDS solutions.

Operational Design and Automation

Design focuses on fault tolerance, redundancy, and self‑evidence, with manual SOPs as a fallback. Standardization covers product interfaces, hardware/software choices, and user experience, ensuring simplicity and orthogonal functionality.

Automation aims to eliminate manual steps, enabling self‑service and reducing hidden operational costs.

Benefits

Improved development efficiency.

Enhanced operational efficiency.

Higher system stability.

Vendor neutrality and cloud freedom.