Blog on SeaGaruda Tech Blog

From Hardware to Software: Rethinking DR Networking in the Cloud Era

Tue, 11 Aug 2026 00:00:00 +0800

In our previous article, we proposed a core thesis: public cloud has transformed disaster recovery from a “hardware engineering” discipline into a “software engineering” one. Many readers resonated with this idea but wanted us to go deeper — what does “hardware becomes software” actually look like in practice?

This article drills into the most complex layer of any DR architecture — network interconnectivity — to unpack that transformation in detail.

Beyond Lift and Shift: Why Cloud Migration Demands Database Code Optimization

Fri, 31 Jul 2026 00:00:00 +0800

The Hidden Trap in Cloud Migration

A familiar story: a company runs its Oracle database on a physical server. The database disks are directly attached — SAS drives in a RAID array, or local NVMe SSDs. The application has worked fine for years. Full-table scans on multi-million-row tables, complex joins without proper indexes, dynamic SQL assembled at runtime — the hardware absorbed it all.

Then the company decides to “go cloud.” They provision an ECS (Elastic Cloud Server) on Huawei Cloud or an EC2 instance on AWS, attach an EVS (Elastic Volume Service) or EBS (Elastic Block Store) disk, copy the database over, start the application, and declare migration complete.

First Time on Managed MySQL: A Practical Guide to Huawei Cloud RDS

Thu, 02 Jul 2026 00:00:00 +0800

Most teams who’ve run MySQL on ECS before have a well-worn mental model: SSH in, edit my.cnf, tail the error log, restart the service. When switching to a managed RDS service for the first time, the technical lift is actually small — but the places where things go wrong are predictable, and almost always tied to habits carried over from self-hosted setups.

This guide walks through the full process of connecting your application to a new Huawei Cloud RDS for MySQL instance, with specific attention to the differences that tend to surprise teams coming from self-hosted MySQL.

Why Most Enterprise Digitalization Fails — and the Only Way Out

Wed, 24 Jun 2026 00:00:00 +0800

An enterprise spends millions deploying ERP, OA, and CRM. Six months later, the operations team is still reconciling accounts in WeChat groups, reporting figures through Excel, and signing approvals on paper.

This is not an edge case. It is the most common — and most fatal — pattern in enterprise digital transformation.

1. The Iron Rule: Informatization First, Then Digitalization, Then Intelligence

There is a strict prerequisite chain that cannot be skipped:

Purdue Model on Public Cloud — Not a Compromise, But an Evolution

Sat, 13 Jun 2026 00:00:00 +0800

Many security teams in traditional industries frown the moment someone mentions moving to public cloud.

The reason is straightforward: we have spent twenty years structuring OT networks around the Purdue Reference Architecture — isolating layers, strictly controlling data flows between them. Now someone wants to send SCADA data to AWS, Azure, or Huawei Cloud? Isn’t that dismantling the entire security boundary?

The concern is reasonable. The conclusion is not necessarily correct. Public cloud is not the opposite of the Purdue Model. It provides a more flexible, more observable way to implement the same layered logic. The question is how you use it.

Load Balancing First: Why Traditional Industry Owners Should Resist the Microservices Jump

Fri, 12 Jun 2026 00:00:00 +0800

There is a recurring pattern in enterprise software upgrades: when a system needs to scale, the conversation jumps straight from “single-server monolith” to “full microservices transformation” — skipping over the more practical middle ground of horizontal scaling with load balancing. This article examines that middle ground from the perspective of the business owner, and explains why it is often the most rational choice.

1. Architecture Solves Specific Problems — Match the Tool to the Problem

The most common source of confusion in architecture discussions is treating different architectural patterns as interchangeable upgrades, when in fact they solve fundamentally different problems.

From Monolith to Distributed: Best Practices and Effort Estimation

Wed, 10 Jun 2026 00:00:00 +0800

Background

Traditional industry software — factory MES, hospital HIS, power SCADA, AMI metering platforms — was born in the monolith era. One deployment package, one database, one server. At the time, that was the most practical choice.

As systems age, connected devices multiply, and user loads grow, the cracks start showing:

Scaling ceiling: traffic spikes require vertical scaling of the entire machine — expensive and inflexible
Single point of failure: one server goes down, the whole system stops
Downtime deploys: every release requires a maintenance window; operations teams hate it
Resource waste: servers idle at off-peak hours, yet can’t handle peak loads

The knee-jerk reaction is often “should we go microservices?” This article argues: distributed deployment with load balancing is the right first step for traditional industry systems. It solves the majority of real problems at a manageable cost. Microservices are a later conversation — when team size and business complexity actually justify it.

PostgreSQL + TimescaleDB on Huawei Cloud vs Oracle for AMI Projects

Tue, 10 Jun 2025 00:00:00 +0800

Overview

Advanced Metering Infrastructure (AMI) is fundamentally a time-series problem. Millions of smart meters report readings at 15-minute or hourly intervals, 24 hours a day. The database at the center of an AMI platform must handle continuous high-volume inserts, fast time-range queries, long-term data retention, and growing device counts — all without planned downtime.

Traditional AMI deployments have relied on Oracle in a primary/standby configuration. This document makes the case that Huawei Cloud RDS for PostgreSQL with TimescaleDB is a technically superior and dramatically more cost-effective alternative for modern AMI platforms such as Gurux.DLMS.AMI.

From On-Premise to Cloud: Why Distributed Architecture Is the Right Move

Sun, 01 Jun 2025 00:00:00 +0800

The Old Way: Physical Servers and Painful Upgrades

Traditional software has long been deployed on physical servers — typically a primary machine and a standby. When business grows and the system can no longer keep up, the only option is to upgrade the hardware: shut down the primary, switch traffic to the standby, add memory and disks, then bring it back online.

This process is disruptive by design. Every capacity upgrade means a maintenance window, user-facing downtime, and a race against the clock. The bigger the system, the more painful the upgrade.