Articles

• 1: From Hardware to Software: Rethinking DR Networking in the Cloud Era
• 2: Beyond Lift and Shift: Why Cloud Migration Demands Database Code Optimization
• 3: First Time on Managed MySQL: A Practical Guide to Huawei Cloud RDS
• 4: Why Most Enterprise Digitalization Fails — and the Only Way Out
• 5: Purdue Model on Public Cloud — Not a Compromise, But an Evolution
• 6: Load Balancing First: Why Traditional Industry Owners Should Resist the Microservices Jump
• 7: From Monolith to Distributed: Best Practices and Effort Estimation
• 8: PostgreSQL + TimescaleDB on Huawei Cloud vs Oracle for AMI Projects
• 9: From On-Premise to Cloud: Why Distributed Architecture Is the Right Move

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

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.

1. The Traditional Data Center Era: Network Interconnection as a “Physical Engineering” Project

In traditional primary-standby data center DR, network interconnection is the most time-consuming and expensive component. Building a cross-DC disaster recovery network requires at minimum:

1.1 Physical Link Procurement and Installation

Leased lines (MSTP/OTN) must be pulled between primary and backup data centers. This involves carrier site surveys, conduit construction, and fiber optic installation. Intra-city dedicated lines typically take 2–4 weeks to deliver; inter-city lines can take 1–3 months. Bandwidth is fixed — if you need more, you go through the entire procurement cycle again.

1.2 Network Equipment Procurement and Configuration

Each data center requires routers, switches, firewalls, and hardware load balancers (e.g., F5). Hardware procurement cycles are typically 4–8 weeks. After delivery, equipment must be racked, cabled, and configured — VLANs, STP, BGP, OSPF. A medium-sized DR network’s device configuration can easily exceed 500 CLI commands.

1.3 The Change Management Nightmare

Any network change — adding a route, modifying an ACL, adjusting a load balancing policy — requires a formal change approval process, a maintenance window, and a network engineer manually typing commands on each device at midnight. A mistake can take down the entire network, and rollback isn’t guaranteed to be fast.

1.4 DR Drills Require Cross-Team Coordination

A single DR drill involves the network team (route changes), systems team (DNS switching), application team (config changes), and database team (primary-replica failover). A dozen people may be involved, and the drill window must be booked weeks in advance. Post-drill, each team must verify state restoration — which is why many enterprises treat DR drills as an annual checkbox exercise.

The core contradiction of traditional DR networking: the network is physical, but failures are instantaneous. You spent three months building a physical DR network that may never be able to complete a switchover in minutes.

2. The Cloud Era: Network Interconnection Becomes “Code-Defined”

Public cloud abstracts the network from “tangible physical devices you can touch” into “programmable logical entities.” VPC (Virtual Private Cloud) is not merely a “virtual network” — it is a complete software redefinition of all network behavior.

Let’s compare traditional physical networking with cloud VPC across four key DR dimensions:

2.1 Link Interconnection: Leased Lines → VPC Peering / Transit Gateway

Traditional: Physical leased lines between data centers. Carrier installation takes weeks. Bandwidth is fixed and expensive.

Cloud: VPC Peering Connections or Transit Gateway (AWS) / Cloud Enterprise Network CEN (Alibaba Cloud) for cross-region interconnectivity. The entire process is an API call — a cross-Region private network link is created in seconds. Alibaba Cloud CEN runs on Alibaba’s global backbone network, eliminating the need for enterprises to maintain their own dedicated lines.

2.2 Routing Configuration: CLI on Each Device → Declarative Route Tables

Traditional: Network engineers log into each router and configure BGP/OSPF via command line. Different vendors have different syntaxes (Cisco IOS vs. Huawei VRP). Configuration inconsistency is a common failure source.

Cloud: VPC route tables are declarative — you define “destination CIDR → next hop” mappings, and the cloud platform implements them at the underlying layer. Modifying a route is as simple as updating a route table entry. A single API call can simultaneously affect hundreds of VMs. No need to worry about BGP neighbors, STP convergence, or other low-level details.

2.3 Security Isolation: Hardware Firewalls → Security Groups / NACLs

Traditional: Hardware firewalls at data center boundaries, VLAN-based internal segmentation. ACL rules are scattered across multiple devices, making auditing difficult and changes risky.

Cloud: Security Groups attach directly to VM network interfaces; NACLs operate at the subnet level. Rules are defined as JSON/YAML, can be version-controlled, and can be diffed. During DR failover, security policies migrate automatically with instances — no more “firewall rules weren’t synced to the DR site.”

2.4 Load Balancing: F5 Hardware → Cloud-Native ALB/NLB

Traditional: F5, A10 hardware load balancers in active-standby mode require config synchronization. Session loss during failover is possible. Scaling requires purchasing new hardware.

Cloud: AWS ALB/NLB, Alibaba Cloud SLB are all managed services with built-in multi-AZ redundancy. Cross-Region traffic distribution uses Route 53 / Cloud DNS failover routing policies. The entire load balancing layer is inherently highly available — no standby appliances to maintain.

3. Infrastructure as Code: The “Executable Version” of DR Configuration

The most致命 (fatal) problem with traditional DR isn’t “can’t do it” — it’s “can’t explain it.” Is the DR data center’s network configuration consistent with production? Were the last changes synchronized? Nobody can say for certain, because configuration is scattered across dozens of devices’ CLIs.

Cloud DR solves this through Infrastructure as Code (IaC):

3.1 VPC Network as Code

Terraform / CloudFormation lets you write the entire DR network topology as code: VPCs, subnets, route tables, security groups, Peering connections, DNS failover records — all defined declaratively. Git commit is the audit trail. Code Review is the change approval. The DR Region’s network environment can be rebuilt from code in one command, no longer dependent on a network engineer’s personal notes.

# disaster_recovery.tf - VPC cross-region DR

resource "aws_vpc_peering_connection" "dr" {
  vpc_id      = aws_vpc.primary.id
  peer_vpc_id = aws_vpc.dr.id
  peer_region = "us-west-2"
  auto_accept = false
}

resource "aws_route53_record" "failover" {
  zone_id = var.zone_id
  name    = "app.example.com"
  type    = "FAILOVER"

  failover_routing_policy {
    type = "PRIMARY"
  }

  set_identifier = "primary"
  records        = [aws_lb.primary.dns_name]

  health_check_id = aws_route53_health_check.primary.id
}

3.2 DR Drills as Pipelines

Traditional drills require a dozen people coordinating for weeks. Cloud drills can be orchestrated as a CI/CD pipeline: terraform apply creates an isolated test environment → inject failures (simulate Region unavailability) → verify DNS switchover and traffic shift → auto-generate drill report → terraform destroy cleanup. The entire process runs unattended and can execute automatically during off-peak hours daily.

3.3 Configuration Drift Detection

Another advantage of IaC: you can periodically run terraform plan to detect “configuration drift” — if someone manually modified a VPC route or security group rule, the next plan will immediately surface the difference. This solves the most painful problem in traditional DR: the DR environment silently diverging from production over time.

4. Three Fundamental Shifts

Shift 1: From “Physical Topology” to “Logical Topology”

Traditional DR network diagrams show physical device connections — which router connects to which switch, which fiber path. Cloud DR network diagrams show logical relationships — which VPC peers with which VPC, which route table points to which CIDR. The physical topology is abstracted and maintained by the cloud platform. You only need to care about whether the logical topology is correct.

Shift 2: From “Device Operations” to “Policy Orchestration”

In the traditional model, a network engineer’s daily work is logging into devices for inspections, troubleshooting alerts, and making configuration changes. In the cloud model, all this low-level operations is handled by the cloud platform. The engineer’s focus shifts upward to policy design — DR routing policies, traffic switching policies, security isolation policies — implemented and validated as code. The operational object changes from “devices” to “policies.”

Shift 3: From “Build Ahead” to “Build on Demand”

Traditional DR requires months of advance hardware procurement and line installation. Cloud DR environments can be spun up from IaC code in minutes when needed. This means you can even choose not to maintain a standing DR environment — just keep the code and data backups, and rebuild from scratch on failure. This is the essence of AWS’s “Backup & Restore” strategy: using code’s rebuildability to replace physical standby servers.

5. Three Pitfalls of Cloud Network DR

Pitfall 1: VPC Quota Limits

Every cloud provider has quota limits on VPC count, Peering connections, route table entries, and security group rules. Large-scale multi-active architectures may hit these ceilings. Proactively request quota increases from your cloud provider during the architecture design phase — don’t discover route table entry limits during a DR failover.

Pitfall 2: DNS Caching is a Silent Killer

Even if the cloud platform’s DNS failover policy is correctly configured, client and intermediate DNS resolver caches can still cause traffic to continue hitting the failed Region. Always set sufficiently short TTLs (60 seconds or lower), and include a “wait for DNS propagation” check step in your DR failover scripts. AWS Route 53 health check intervals should also be set to 10 seconds rather than the default 30.

Pitfall 3: Cross-Region Bandwidth Costs

VPC Peering and Transit Gateway cross-Region traffic incurs charges. AWS cross-Region data transfer is approximately $0.01–0.02/GB; Alibaba Cloud CEN cross-region bandwidth packages have corresponding fees. For data-intensive workloads (e.g., continuous database replication), these costs can be significantly higher than expected. Restrict cross-Region sync to critical data; use asynchronous batch sync for non-critical data.

Conclusion

Returning to our core thesis: public cloud has transformed disaster recovery from a “hardware engineering” discipline into a “software engineering” one.

At the network layer, this means — the fiber, routers, firewalls, and load balancers you used to procure are now all configuration items inside a VPC. The DR network that used to take months to build is now the execution time of a Terraform script. The DR drill that used to require a dozen people is now a CI pipeline.

This is not an incremental improvement — it’s a paradigm shift. When the DR network goes from a “physical entity” to a “code definition,” it inherits all the advantages of code: version management, automated testing, rapid replication, audit traceability.

In the cloud era, the best DR network isn’t “an extra leased line” — it’s “a tested piece of code.” When failure strikes, code runs faster than cable.

References: AWS Well-Architected Framework, Alibaba Cloud CEN Product Documentation, Terraform Official Documentation

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

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.

The result? Performance collapses. Reports that ran in 30 seconds now take 5 minutes. Batch jobs that finished overnight are still running at noon. Users complain. Management questions the cloud decision. The team scrambles to upgrade the EVS disk to a more expensive tier — and still the performance is worse than the old physical server.

The problem is not the cloud. The problem is that the code was never optimized for how cloud storage actually works.

Why Cloud Storage Performs Differently

Physical Server: Direct-Attached Storage

On a physical server, the Oracle database runs on disks that are directly connected to the motherboard — typically a RAID array of enterprise SAS drives or local NVMe SSDs. The key characteristics:

• IOPS: A 12-drive RAID 10 array of 15K SAS drives delivers 1,200–2,400 random IOPS. A single NVMe SSD delivers 500,000+ IOPS. No artificial caps.
• Throughput: RAID arrays deliver 1–4 GB/s sequential throughput; NVMe SSDs reach 5–7 GB/s.
• Latency: 2–8 ms for SAS, sub-millisecond for NVMe. No network hop.
• No IOPS provisioning: The hardware delivers whatever it can, whenever it can. There is no per-disk IOPS quota.

Cloud ECS with EVS/EBS: Network-Attached Block Storage

Cloud block storage (EVS on Huawei Cloud, EBS on AWS, Managed Disks on Azure) is fundamentally different. The disk is not inside the server — it is a network-attached storage resource accessed over the hypervisor’s storage network.

The critical difference is not the peak numbers — it is the capping mechanism. On a physical server, the disk delivers its full capability at all times. On cloud block storage, IOPS and throughput are provisioned and capped per disk. Exceed the cap, and I/O requests queue up. The disk does not degrade gracefully — it hard-throttles.

The Multiblock Read Problem

This is where Oracle’s I/O architecture collides with cloud storage caps.

Oracle uses DB_FILE_MULTIBLOCK_READ_COUNT to read multiple database blocks in a single I/O operation during full table scans. On a physical server with a large OS I/O size (e.g., 1 MB), Oracle can read 128 blocks (at 8 KB block size) in one I/O call. The hardware handles it transparently.

On cloud block storage, this single I/O call may be counted as multiple I/O operations by the storage backend. As AWS migration specialist Yavor Ivanov documented: “This single IO call from the Oracle engine will be counted as 4 IO operations by EBS. This matters a lot because, no matter if you use IO1/IO2 or GP2/GP3 volumes, you do have a limit of the IOPS, and it is not as high as in Exadata.”

In other words, a single Oracle multiblock read can consume 4× the IOPS budget on cloud storage compared to what it consumed on physical hardware. Full table scans — which were tolerable on bare metal because the disk had no IOPS cap — become IOPS-eating monsters in the cloud.

Real-World Evidence

Case 1: Oracle to Azure Cloud — Storage Bottlenecking

A migration team moving Oracle databases to Azure documented that “I/O latency increased during replay tests using Database Replay (RAT) compared to capture in the on-prem environment. The culprit was storage bottlenecking — the chosen Premium SSD simply couldn’t deliver the I/O throughput the on-prem SAN provided.” The fix was not just upgrading to Ultra Disk — it was also rewriting the worst-performing SQL queries to reduce I/O volume.

Case 2: The $100K Lift-and-Shift Failure

A company migrated its monolithic application to the cloud using pure lift-and-shift. The result: “The architecture didn’t change. Only the hosting bill did. Migration is not modernization. Moving a monolith to the cloud gives you a cloud-hosted monolith.” The application’s database queries — designed for local SAN storage — saturated the cloud disk’s IOPS cap within hours. The company spent $100K before realizing that code-level SQL optimization was the missing step.

Case 3: British Airways — The Cautionary Tale

The 2017 British Airways outage, while not solely a database issue, illustrated the core lesson: moving workloads without adapting them to the new environment creates cascading failures. A lift-and-shift of its booking system to a hybrid cloud contributed to 20 hours of downtime, 672 canceled flights, and an estimated $100 million in losses.

Case 4: Oracle on AWS — IOPS Saturation in Production

When migrating Oracle Exadata workloads to AWS, engineers found that multiblock reads saturate cloud storage in two ways simultaneously: “by sheer volume of data transferred — hit the throughput limit — or consuming all the IOPS you have, provisioned or not.” On Exadata, smart scans offload I/O to storage cells. On EBS, there is no such offload. Every full scan hits the disk cap directly.

What Needs to Change in the Code

Cloud migration is not just about moving the database — it is about optimizing how the application talks to the database. Here are the key code-level changes required:

1. Eliminate Full Table Scans

On physical servers, SELECT COUNT(*) FROM large_table or SELECT * FROM orders WHERE status = 'PENDING' without an index was tolerable — the disk was fast enough. In the cloud, these queries eat IOPS budget and block other operations.

Action: Audit all SQL statements. Add appropriate B-tree indexes. Use index-only scans where possible. For analytical queries, consider materialized views.

2. Replace Dynamic SQL with Parameterized Queries

Dynamic SQL (string concatenation of query fragments) prevents Oracle from caching execution plans. On physical hardware, the cost of re-parsing was absorbed by CPU. In the cloud, suboptimal execution plans lead to full scans that hit IOPS caps.

Action: Use bind variables. Pre-compile frequently-used query patterns. Enable cursor sharing.

3. Implement Pagination at the Database Level

Applications that fetch all rows and paginate in memory (e.g., SELECT * FROM huge_table then slice in Java/C#) worked when disk I/O was free. In the cloud, this is catastrophic.

Action: Use OFFSET ... FETCH FIRST N ROWS ONLY (Oracle 12c+) or ROWNUM-based pagination. Never fetch more rows than the page needs.

4. Optimize Batch Operations

Batch jobs that loop through rows one-by-one, issuing individual UPDATE or INSERT statements, generate thousands of small random I/O operations — the worst-case scenario for cloud storage.

Action: Use bulk operations (FORALL in PL/SQL, batch JDBC in Java). Use MERGE instead of separate UPDATE/INSERT logic. Reduce round-trips.

5. Add Connection Pooling and Statement Caching

On a physical server with a local database, connection overhead was negligible (sub-millisecond TCP on localhost). In the cloud, even with the database on the same ECS, connection establishment and cursor allocation consume resources that compound under load.

Action: Use connection pooling (Oracle UCP, HikariCP). Enable implicit statement caching. Set appropriate pool sizes based on ECS vCPU count.

6. Partition Large Tables

Tables with tens of millions of rows that are scanned entirely for reporting queries are prime candidates for partition pruning. On cloud storage, partition pruning reduces I/O by orders of magnitude.

Action: Implement range or list partitioning on large tables. Ensure queries include partition-key predicates. Use local indexes.

7. Re-evaluate PL/SQL Bulk Collect Limits

BULK COLLECT with LIMIT clause controls how many rows Oracle fetches per round-trip. On physical servers, a large LIMIT (e.g., 1000) was fine. On cloud storage, the I/O pattern of large bulk collects may hit throughput caps.

Action: Benchmark different LIMIT values (100, 500, 1000) in the cloud environment. Tune based on actual cloud storage behavior, not on-prem habits.

The Optimization Workflow

Phase 1: Baseline          Phase 2: Audit           Phase 3: Optimize
─────────────────          ──────────────          ───────────────
  Capture AWR reports       Identify top SQL         Add indexes
  Record response times     by elapsed time          Rewrite queries
  Profile I/O patterns     Find full table scans     Add partitioning
  Document baseline        Check missing indexes     Batch operations
                            Review execution plans   Pool connections

Phase 4: Validate          Phase 5: Monitor
─────────────────          ───────────────
  Re-run workload          Set up Cloud Eye
  Compare to baseline      /CloudWatch alerts
  Load test               Monitor IOPS utilization
  Regression test         Track SQL performance

Effort Estimation for Database Code Refactoring

Based on industry migration case studies and real-world Oracle-to-cloud projects, here is a realistic effort breakdown for a mid-sized application (50–100 database tables, 200–500 SQL statements to audit):

Assessment Phase

Subtotal: 9–15 person-days

Optimization Phase

Subtotal: 25–47 person-days

Validation & Deployment Phase

Subtotal: 8–13 person-days

Summary

For a typical team of 2 developers + 1 DBA working in parallel, this translates to approximately 6–12 weeks of dedicated effort.

Key Variables That Shift the Estimate

• Application size: 50 tables vs. 500 tables shifts the estimate by 3–5×.
• Code quality: Well-structured code with clear data access layers is faster to optimize than scattered inline SQL across hundreds of source files.
• SQL complexity: Simple CRUD queries take 0.5–1 hour each. Complex analytical queries with multiple subqueries and UNIONs can take 1–2 days each.
• Testing infrastructure: If a staging environment with production-like data volumes exists, validation is faster. If not, add 5–10 person-days for test data setup.
• Team experience: Developers familiar with Oracle execution plans and AWR analysis work 2–3× faster than those learning on the job.

Cost of Inaction

Failing to optimize database code during cloud migration is not free — it just defers the cost:

As one practitioner put it: “When you move a monolithic SQL Server or Oracle database into an AWS EC2 or Azure VM environment without refactoring, you are essentially paying a premium to rent someone else’s hardware to run inefficient, legacy code.”

Conclusion

Cloud migration is not a copy operation. It is a transformation that demands changes at every layer — infrastructure, architecture, and code. The database, in particular, requires careful attention because cloud storage behaves fundamentally differently from direct-attached disks:

1. IOPS are capped, not unlimited. Full table scans that were tolerable on bare metal become IOPS-eating bottlenecks in the cloud.
2. Multiblock reads are counted differently. A single Oracle I/O call may consume multiple IOPS on cloud storage, accelerating cap exhaustion.
3. Throughput has hard limits. Cloud EVS/EBS disks throttle when the limit is hit — they don’t degrade gracefully.

The solution is not to throw more expensive storage at the problem. It is to optimize the code: eliminate unnecessary full scans, add indexes, use bind variables, implement pagination, batch operations, and partition large tables.

For a mid-sized application, this optimization effort is 6–12 weeks of dedicated work — a fraction of the cost of running an over-provisioned, under-performing cloud deployment for even a single year.

The cloud does not make your database faster. It makes your optimization decisions matter.

References

• Oracle Help Center, “DB_FILE_MULTIBLOCK_READ_COUNT” — docs.oracle.com
• Yavor Ivanov, “Migrating Exadata Workloads to AWS, Part Five: EBS Volumes for Oracle DBAs” — LinkedIn
• DBA Insight, “Migrating Oracle Databases to Azure Cloud — Performance Validation and Lessons Learned” — dbainsight.com
• Thomas Nys, “The $100K Cloud Migration Mistake” — thomasnys.com
• Huawei Cloud, “EVS Disk Types and Performance” — support.huaweicloud.com
• AWS, “Determining IOPS Needs for Oracle Database on AWS” — docs.aws.amazon.com
• Oracle, “Moving Databases to Oracle Cloud: Performance Best Practices” — oracle.com
• PerformanceOne, “Beyond the Lift and Shift: Cloud Migration Cost Optimization” — performanceonedatasolutions.com
• Jose Carlos Moreira, “Best Practices for Optimizing Oracle Database Performance in Cloud Environments” — Medium

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

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.

Implementation Steps

1. Create the RDS Instance

When provisioning the instance in the Huawei Cloud console, one decision matters above everything else: the Region and VPC must match your business ECS.

This is not adjustable after the fact. Once an RDS instance is created, its VPC assignment is fixed. If you later discover the RDS and ECS are in different VPCs, your options are to rebuild the instance or configure VPC peering — both are avoidable headaches. Getting Region and VPC right at creation time is the foundation for everything that follows.

2. Initialize the Database and Credentials

Once the instance is running, use the RDS console to:

• Create the target database(s) for your application
• Create a dedicated database user — do not use the root account for application connections
• Grant only the permissions the application actually needs: typically SELECT, INSERT, UPDATE, DELETE, CREATE, and DROP

Least-privilege matters here. An application account that can only do what it needs limits the blast radius if credentials are ever compromised.

3. Update the Application Configuration

Locate your application’s database configuration file and update the connection parameters:

Prefer the RDS internal domain name over the internal IP. The domain name remains stable across primary/standby failovers; the IP address may change. Using the domain means your application survives a failover without a config update.

4. Verify Network Connectivity

Before restarting your application, test the connection from the ECS directly:

mysql -h <RDS-internal-address> -u <username> -P 3306 -p

Or test the port first if MySQL client isn’t installed:

telnet <RDS-internal-address> 3306

If this fails, check the security group first — it’s the most common cause of connectivity failures for new RDS users. See the section below.

5. Start the Application and Run Full Tests

With connectivity confirmed and config updated, start the application and run a complete functional regression. Verify that all read and write paths work as expected before treating the deployment as done.

Things That Catch First-Time RDS Users

These are the areas where managed RDS behaves differently from self-hosted MySQL — and where most issues originate.

⚠️ Security Group Rules (the #1 issue)

RDS does not expose port 3306 to anything by default. You need to explicitly allow access:

1. Find the security group attached to your RDS instance
2. Add an inbound rule: Protocol TCP, Port 3306, Source = the internal IP of your ECS (e.g. 192.168.1.10/32)

Resist the temptation to set the source to 0.0.0.0/0. That exposes the database port to the entire VPC or beyond. Restrict it to the specific IPs that need access.

⚠️ Character Set and Timezone

A freshly created RDS instance doesn’t necessarily default to utf8mb4. If your application handles emoji, East Asian characters, or any non-BMP Unicode, verify this before loading data:

SHOW VARIABLES LIKE 'character_set_%';
SHOW VARIABLES LIKE 'time_zone';

Set these explicitly in the RDS console under Parameter Groups:

character_set_server = utf8mb4
collation_server     = utf8mb4_unicode_ci
time_zone            = Asia/Shanghai

Timezone mismatches are particularly insidious — they cause DATETIME values to shift silently on read, and the symptom often looks like a bug in application logic rather than a configuration issue.

⚠️ Key Parameters to Review

RDS ships with a default parameter group that may differ from your self-hosted configuration. Three parameters deserve specific attention:

lower_case_table_names (table name case sensitivity)

On RDS for MySQL 8.0, this parameter cannot be changed after instance creation. You must decide at provisioning time:

• 0 — case-sensitive (Linux default, recommended for production)
• 1 — case-insensitive (common on Windows; needed when migrating from a Windows-hosted MySQL)

If you’re migrating an existing database, verify what the source instance uses before creating the RDS instance.

innodb_flush_log_at_trx_commit and sync_binlog

Both default to 1 on RDS, meaning every transaction commit forces a disk flush. This is the safest configuration but has a write performance cost.

If your workload is write-intensive and you’ve benchmarked a bottleneck here, you can tune these — but understand the trade-off before doing so.

⚠️ You No Longer Manage the OS

This is the most significant mindset shift, and it’s worth being explicit about it.

With self-hosted MySQL, your operational toolkit is SSH + a text editor + systemctl. With RDS, none of that exists. There’s no shell, no config file to edit directly, no service mysql restart.

The mapping looks like this:

This is a feature, not a limitation — it means Huawei Cloud is handling HA, failover, and backup infrastructure. But it requires learning to operate through the console and API rather than the command line.

⚠️ Set a Backup Policy That Fits Your Business

RDS enables automated backups by default, but the default settings may not match your recovery requirements. Configure these early:

• Backup window: set to off-peak hours (e.g. 02:00–04:00)
• Retention period: default is 7 days; adjust to 14–30 days based on criticality
• Test restores periodically: a backup you’ve never restored from is a backup you can’t rely on

Summary

The migration itself is straightforward: update the connection config, align a handful of parameters, confirm the network path is open, and test.

The places that actually cause problems are almost always the same three: security group rules blocking port 3306, character set or timezone mismatches discovered only after data is in the database, and lower_case_table_names set wrong because it wasn’t checked before the instance was created.

Address those three upfront and the rest of the cutover is mostly mechanical.

4 - Why Most Enterprise Digitalization Fails — and the Only Way Out

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:

• Informatization: Business processes live in the system. Transactions generate records. Paperless operations.
• Digitalization: Decisions are driven by real data from those systems — analytics, insights, operational dashboards.
• Intelligence: High-quality data feeds AI models that predict, optimize, and automate.

You cannot reach step two without completing step one. You cannot reach step three without completing step two.

The reality is sobering. A 2020 IDC China survey found that only 2.7% of Chinese enterprises had completed full-scale digital transformation of core business processes. The China Academy of Information and Communications Technology (CAICT) reported in 2022 that 55.8% of enterprises cited data silos as their single biggest barrier.

The root cause is almost always the same: the data inside the system is corrupted.

2. Shadow IT: The Silent Drain on Your Data Assets

When enterprise systems feel slow, rigid, or disconnected from actual workflows, employees build workarounds. Researchers call this Shadow IT.

Gartner’s 2023 report found that 41% of enterprise employees acquired, modified, or created technology capabilities outside of IT’s visibility — up from 35% the year before. Cisco found that 80% of employees admitted to using non-approved SaaS applications for work.

Why do workers bypass official systems? Salesforce’s research identified three reasons:

Each of these sounds reasonable in isolation. Together, they produce a catastrophic outcome: every workaround generates data that never enters the official system. That data lives in chat histories, spreadsheet files, and paper forms — invisible to management, invisible to analytics, and invisible to AI.

MIT Sloan research established that only 3% of companies’ data meets basic quality standards (MIT/Tamr, 2017). IBM estimated that poor data quality costs U.S. businesses $3.1 trillion per year (IBM, 2016).

The downstream impact on AI is direct. NewVantage Partners’ 2023 executive survey found that 68% of enterprises identified data quality and data governance — not algorithmic capability — as the primary obstacle to AI and analytics initiatives. Gartner’s 2022 prediction is equally blunt: through 2025, 80% of AI projects will depend more on data quality than on model sophistication.

No clean data, no AI. It is that simple.

3. “The System Doesn’t Fit Our Workflow” Is a Signal to Upgrade — Not a License to Bypass

The instinctive managerial response to shadow IT is accommodation: let the team handle it their own way. This path leads nowhere.

Business conditions change. Market demands shift. An information system that cannot keep up with those changes will always have gaps, and those gaps will always produce offline workarounds.

The correct response to a gap in the system is: turn the gap into a product requirement and close it through iteration — fast.

Traditional IT procurement cannot do this. Forrester Research (2021) measured the gap directly: the average time from requirement to production for traditional enterprise software procurement is 7.8 months. Cloud-native SaaS delivers the same capability in an average of 4.3 weeks — more than six times faster.

By the time a traditional project closes the gap, the business has already invented a workaround and institutionalized it.

The scale of the broader failure is well documented. McKinsey (2018) and BCG (2020) independently estimated that 70% of large-scale digital transformation projects fail to achieve their stated goals. Everest Group (2022) put it more starkly: 73% of enterprise digitalization initiatives produce no measurable business value whatsoever.

The two most common failure causes: requirements that did not match actual business reality, and data quality too poor to support decision-making.

4. Cloud-Native Is Not an Option — It Is the Only Viable Infrastructure

The DORA (DevOps Research and Assessment) State of DevOps Report quantifies the performance gap between organizations with cloud-native maturity and those running traditional stacks:

These are not theoretical projections. They are measured outcomes from real organizations, published annually.

VMware’s 2022 report found that organizations with cloud-native maturity delivered features 72% faster. Accenture found cloud-native enterprises were 2.4 times more likely to exceed revenue targets than peers on legacy stacks.

A fixed-scope software procurement contract locks both the iteration speed and the business outcomes ceiling. It structurally cannot support the continuous adaptation that real digitalization requires.

The only infrastructure that can: public cloud foundation + cloud-native architecture + DevOps continuous delivery.

5. In the AI Era, In-House Talent Is the Core Productivity Asset

There is a variable that most enterprise IT strategies have not yet internalized: AI-assisted programming (vibe coding) is fundamentally changing who can build software.

GitHub and Microsoft’s 2022 controlled study found that developers using AI coding assistants completed tasks 55% faster. An NBER working paper (Peng et al., 2023) measuring real-world outcomes across 95 developers found a 26% speed improvement in production settings. McKinsey Digital (2023) estimated generative AI coding tools could improve overall developer productivity by 20–45%, with the largest gains in documentation, test generation, and boilerplate.

Stack Overflow’s 2023 Developer Survey found that over 70% of developers were already using or planning to use AI coding tools.

The implication for enterprise IT strategy is significant: a business-domain expert with access to AI tools can today build systems that previously required an entire outsourced development team. And that person has something no external vendor ever has: they know exactly where the process breaks down, where the exceptions occur, and where the data goes wrong.

Gartner’s 2022–2023 CIO surveys documented a structural insourcing trend: 64% of CIOs reported bringing previously outsourced capabilities back in-house, driven by domain knowledge loss, IP ownership concerns, and the slow response times of external vendors.

The Standish Group CHAOS Report (2020) measured the outcome gap directly: outsourced IT projects have a failure or severely challenged rate of approximately 66%, compared to roughly 50% for in-house projects. Deloitte’s Global Outsourcing Survey (2022) found that 54% of enterprises had experienced a completely failed outsourcing relationship.

Now consider the traditional procurement cycle: define requirements → publish tender → vendor comparison → development → acceptance testing → deployment. The timeline is typically one to two years. By the time the system ships, the business context has changed. The delivered system addresses a stale specification. It does not fit the current workflow. Employees bypass it. The cycle repeats.

This path cannot produce genuine digitalization. Not because the vendors are incompetent — but because the model itself is structurally incompatible with the pace of business change.

6. The Conclusion: Invest in Internal Talent — It Is the Highest-ROI Strategic Decision Available

The logic chain holds together:

1. Informatization is the prerequisite for digitalization; digitalization is the prerequisite for intelligence.
2. When systems are bypassed, data leaves the system and the information layer corrupts.
3. Traditional procurement models cannot iterate fast enough to close the gaps before workarounds become entrenched.
4. Public cloud + cloud-native architecture + DevOps is the only infrastructure capable of sustaining continuous iteration.
5. AI coding tools have raised internal developer productivity to the point where domain-expert employees can outperform external teams on fit-for-purpose software.
6. The traditional write-requirements → tender → outsource cycle is too slow, too misaligned, and too disconnected from business reality to ever achieve true digitalization.

For any enterprise with genuine digital ambitions, the highest-leverage investment available today is: recruit and develop internal talent who understand both the business domain and modern development tooling, give them cloud-native infrastructure and AI coding tools, and let them iterate continuously on systems that actually fit how the business works.

This is not a cost. It is the foundational capital investment that determines whether every other digitalization effort pays off or goes to waste.

Digitalization is not a one-time IT project. It is a continuous process of business evolution. Organizations that stop iterating fall behind. The only question is how fast you want to move.

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

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.

1. What the Purdue Model Is Actually Protecting

The Purdue Enterprise Reference Architecture (PERA), proposed by Theodore Williams in the 1990s and later adopted by ISA-99 / IEC 62443 as the de facto baseline for industrial control security, has one core principle: controlled data-flow management between functional levels — not physical isolation.

The essence of the model: adjacent levels may communicate, but only through controlled, unidirectional or explicitly bidirectional interfaces. Direct cross-level access is prohibited. Separating physical data centers is one way to achieve this — not the only way.

2. How Public Cloud Maps to Purdue Zones

A public cloud is far more than renting servers. Its network and access-control capabilities map precisely onto every Purdue boundary.

VPC and Subnet Isolation

Level 3 systems (MES, historians) and Level 4 systems (ERP) can be deployed in separate VPCs or subnets. Subnets are isolated by default; data flows only when routing rules are explicitly configured. This is logically identical to VLAN segmentation in a physical data center.

Two-Layer Policy: Security Groups + Network ACLs

Security groups provide stateful, instance-level firewall rules. Network ACLs provide stateless, subnet-level rules. Combined, they give precise control over who can reach what, on which protocol, through which port — exactly the inter-level access policies the Purdue Model requires.

Cloud-Native DMZ

A traditional DMZ is a physically isolated network segment running data diodes or unidirectional gateways. On public cloud, an equivalent DMZ is built with an isolated subnet, reverse proxy, WAF, and traffic mirroring. The result has stronger observability: every packet traversing the DMZ can be deep-packet inspected and logged.

Private Connectivity (PrivateLink / Dedicated Line)

Level 2 SCADA data flowing up to cloud-hosted Level 3 does not need to traverse the public internet. Dedicated lines (AWS Direct Connect, Azure ExpressRoute, Huawei Cloud Direct Connect) or private link services provide physically or logically isolated paths from the plant floor to the cloud — satisfying the OT requirement that control networks must never be exposed to the internet.

IAM and Zero-Trust Access Control

Cloud IAM delivers finer-grained control than traditional firewall rules: not just whether an IP address can connect, but which service account, at what time, from which source IP, invoking which API, operating which data record. The principle of least privilege can actually be enforced.

3. A Typical Reference Architecture

Using Advanced Metering Infrastructure (AMI) or smart grid as an example:

[ Field Layer — Level 0–2 ]
  PLC / RTU / Smart Meters
       ↓  (IEC 60870 / MQTT / Modbus)
[ Edge Gateway — Level 3 Boundary, on-premises ]
  Data acquisition, protocol conversion, local buffering
       ↓  (Encrypted dedicated line / SD-WAN / PrivateLink)
[ Cloud DMZ Subnet ]
  Message queue, data gateway (no business logic)
       ↓  (Internal routing, strict ACL)
[ Cloud Level 3 Subnet ]
  Time-series database (TimescaleDB / InfluxDB)
  Device management platform / alerting engine
       ↓  (Application-layer API, read-only)
[ Cloud Level 4 Subnet ]
  ERP integration / BI reporting / external API gateway

Every boundary in this architecture is controlled:

• Edge-to-cloud traffic travels over a dedicated line, never the public internet
• The DMZ subnet handles protocol translation and message relay only — it holds no business data
• Level 3 to Level 4 exposes read-only APIs, with no shared database access
• All network access rules are managed as Infrastructure-as-Code: auditable, version-controlled, and rollback-capable

4. The Challenges That Actually Require Attention

Moving to cloud does not automatically mean compliance. Several areas require serious work:

Edge-side hardening cannot be skipped. No matter how well the cloud architecture is designed, a vulnerable edge gateway allows lateral movement into Level 2 or even Level 1. The Purdue Model requires securing the field-side devices and applying network micro-segmentation on-premises. Cloud does not replace this work.

The shared responsibility model must be understood clearly. The cloud provider’s responsibility ends at the infrastructure layer. Subnet configuration, security group rules, and IAM policies are the tenant’s responsibility. When auditors review compliance, they inspect your configuration — not the cloud provider’s certification documents.

Logs and observability must be unified. Traditional OT environments often store logs locally, or generate no logs at all. After moving to cloud, VPC flow logs, API call logs, security group change logs, and field-device logs must all feed into a unified SIEM. Without this, cross-layer attack paths are invisible.

Compliance standards require line-by-line gap analysis. IEC 62443, NERC CIP, and GB/T 36323 were written before public cloud became widespread. Some provisions assume physical partitioning. A cloud migration requires a formal gap analysis that explicitly documents which cloud-native mechanism serves as the equivalent substitute for each traditional physical control. This documentation is the core material for conversations with regulators.

5. What Cloud Adds That Traditional Data Centers Cannot Match

The Purdue Model was designed to be implemented with the tools of its era. Public cloud provides capabilities that make the implementation more rigorous, not less.

Software-defined policy is auditable by default. Security group rules and network ACLs are version-controlled, peer-reviewed, and change-logged. No one can bypass a zone boundary by plugging a cable into the wrong switch port.

Tamper-proof logging at every level. CloudTrail, Azure Monitor, and equivalent services provide continuous audit logs of every API call, every network connection, every access attempt — across all Purdue levels simultaneously. Most traditional OT networks have nothing comparable.

Zero-trust maintenance access. Remote vendor access — historically the Achilles heel of Purdue implementations — can be enforced through identity-verified, session-recorded, time-limited access with no persistent credentials. This is structurally more secure than a shared VPN password to the “OT VLAN.”

Continuous compliance posture verification. AWS Security Hub, Microsoft Defender for IoT, and Huawei Cloud Security Center continuously verify that zone isolation is maintained, flag configuration drift, and generate audit evidence automatically. Compliance becomes a continuous state, not a point-in-time assessment.

Conclusion: Security Boundaries Were Never Physical

The Purdue Model never required Level 3 to run on a server in your own machine room. It required controlled data-flow direction and access policies between levels.

Public cloud provides stronger tools to implement those policies: finer permission granularity, more complete audit logs, faster policy-change response, and compliance evidence that is easier to quantify and verify.

Moving OT workloads to public cloud is not a way around the Purdue Model. It is an upgrade — from a network topology diagram into a security policy framework that can be codified, versioned, and automatically verified.

Not a compromise. An evolution.

This article is intended for security architects, OT network engineers, and compliance teams evaluating the feasibility of moving industrial control systems to public cloud. If you are working on a specific architecture design or IEC 62443 gap analysis, feel free to leave a comment.

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

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.

Multi-node load balancing addresses availability and horizontal scalability: when one server fails, traffic automatically routes to others; when user volume grows, adding nodes absorbs the additional load. The application code stays largely intact.

Microservices architecture addresses organizational complexity and release independence: large teams are split into smaller groups, each owning a distinct service, capable of deploying without coordinating with every other team. Its primary value is team efficiency at scale, not raw performance.

For most enterprise internal systems — ERP, MES, OA, CRM — concurrent users number in the hundreds to low thousands. The bottleneck is rarely raw throughput. What business owners actually need is high availability and controlled scalability, which load balancing delivers directly.

2. Honest Engineering: Load Balancing Requires Real Code Changes

It would be misleading to describe the monolith-to-load-balanced transition as “no code changes required.” There are genuine engineering tasks involved, and they deserve clear-eyed assessment:

Session Management Centralization

In a single-server deployment, user session state lives in local memory. In a multi-node setup, every node must be able to read the same session data. The standard solution is migrating session storage to a centralized Redis instance. This is the most frequently underestimated work item.

Distributed Lock for Scheduled Tasks

If the application runs scheduled jobs — daily reports, periodic sync tasks, batch processing — deploying multiple instances will cause duplicate execution. The fix is introducing a distributed lock mechanism (Redis-based locks, or Quartz’s cluster mode) to ensure only one node executes each job per cycle.

Local Cache Consistency

In-process caches (Guava, Ehcache) are node-local by definition. Multi-node deployments create the risk of stale or inconsistent cache state across nodes. The typical resolution is migrating hot-path caches to Redis, or explicitly accepting short-term inconsistency where business logic permits.

These are real engineering tasks, but they have well-defined boundaries. For a team with reasonable experience, assessment and implementation typically take four to eight weeks — a manageable window with clear validation criteria at each step.

3. Public Cloud Has Fundamentally Changed the Infrastructure Cost Equation

One historically valid objection to load-balanced architectures was cost: in the on-premise era, hardware load balancers (F5 and equivalents) were expensive, and running multiple application servers meant proportionally higher hosting costs. That objection is largely obsolete in a public cloud context.

Public cloud shifts infrastructure operations to the provider. The monthly baseline cost of a load-balanced two- or three-node deployment is well within budget for most mid-sized enterprises, with no upfront capital commitment and the ability to scale down when demand drops.

4. What Microservices Actually Requires — A Realistic Assessment

Microservices are not a bad architecture. They are the right architecture for specific conditions, and those conditions are worth stating precisely.

High Code Invasiveness

Microservices transformation requires decomposing an existing system into independently deployable services — redesigning service boundaries, defining inter-service APIs, and often splitting the database. For systems that have accumulated years of business logic, this is high-risk work with difficult-to-predict timelines. It is not uncommon for estimates of six months to extend to two years in practice.

Substantial Operational Infrastructure

A production-grade microservices environment requires: service registry and discovery (Nacos, Consul), API gateway, centralized configuration management, distributed tracing (SkyWalking, Jaeger), and typically a message broker. Each component adds operational surface area, requires dedicated expertise, and represents an additional failure point.

Team Capability Requirements

Microservices architecture is difficult to operate well. Organizations without prior experience frequently encounter subtle failure modes — cascading timeouts, partial failures, distributed transaction edge cases — that are much easier to introduce than to diagnose. When evaluating supplier proposals, requesting evidence of comparable delivered projects is a reasonable due diligence step.

5. A Decision Framework for Business Owners

Architecture selection should be driven by current business needs and team capabilities, not by trend or supplier preference. The following heuristics are a starting point:

Load balancing is likely the right choice when:

• Concurrent users are in the hundreds to low thousands
• The primary requirement is fault tolerance and automatic failover, not elastic scaling
• The development team has fewer than 20 engineers
• Delivery timeline needs to be contained to one to three months
• The organization does not have dedicated infrastructure operations capability

Microservices may be worth considering when:

• Daily active users exceed 100,000
• Specific modules require independent deployment or scaling on different cadences
• A mature DevOps function exists (separate development, operations, and SRE roles)
• Observability infrastructure (logging, tracing, metrics) is already in place

6. Recommended Path: Staged Evolution

Architecture does not need to be solved in a single transformation. A staged approach reduces risk and allows each phase to be validated before committing to the next:

Phase 1 — Load-balanced monolith: Migrate session storage to Redis, add distributed lock for scheduled tasks, deploy two to three application nodes behind a cloud load balancer. Validate availability and performance under realistic load.

Phase 2 — Selective service extraction (if needed): Identify modules with genuinely distinct scaling profiles or release cadences. Extract those as independent services while leaving the core monolith intact. This is the “strangler fig” pattern — incremental, reversible, and risk-proportionate.

The value of this approach is that each phase has a clear cost, a defined scope, and measurable outcomes. Business owners can make go/no-go decisions at each boundary rather than committing to a multi-year transformation upfront.

Conclusion

For traditional industry software serving enterprise-scale workloads, load-balanced horizontal scaling represents the most cost-effective upgrade path available today. The engineering work is real but bounded. On public cloud, the infrastructure costs are controlled and proportional to actual usage. The operational complexity stays within what most teams can manage.

Jumping directly to microservices typically brings organizational and operational overhead that is disproportionate to the problems being solved — at least until the business genuinely outgrows what a well-operated distributed monolith can handle.

When reviewing supplier proposals, the most useful questions are not about which architectural buzzwords appear in the document. They are: what specific problem does this architecture solve for us today, what does the engineering scope look like, and what does the supplier’s track record with comparable deployments look like?

Those answers tend to be more revealing than the architecture diagram.

7 - From Monolith to Distributed: Best Practices and Effort Estimation

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.

1. Target State: What the System Looks Like After Migration

After migration, the system should reach this topology:

                    ┌──────────────────────────────────────┐
Users / Devices ──▶ │   Nginx Load Balancer / API Gateway   │
                    └───────────┬──────────────┬────────────┘
                                │              │
                       ┌────────▼───┐  ┌───────▼────┐
                       │  App Node 1 │  │  App Node 2 │  ← scale horizontally
                       └────────┬───┘  └───────┬────┘
                                │              │
              ┌─────────────────▼──────────────▼──────────────┐
              │   Shared Database (primary/replica read split)  │
              │   Primary (writes) + Read Replica (queries)     │
              └────────────────────────────────────────────────┘
              ┌────────────────────────────────────────────────┐
              │   Redis (shared session / cache / dist. locks)  │
              └────────────────────────────────────────────────┘

Core gains:

• High availability: one node crashes, traffic routes to others — users notice nothing
• Horizontal scaling: add a machine, start an instance, capacity grows linearly
• Rolling deploys: replace nodes one at a time, no maintenance windows
• Database relief: read/write split means reporting queries no longer block the primary

2. The Core Work: Making the Application Stateless

Multi-instance deployment requires a stateless application — any instance must be able to handle any request without depending on data local to a specific machine.

Monolith systems typically carry four categories of state that need to be addressed.

2.1 Session Migration

Problem: Sessions live in JVM heap memory. After login, requests must hit the same machine. Add a second instance and sessions break.

Fix: Move sessions to Redis, shared across all instances.

// Spring Boot: one dependency + config, almost no code change
// pom.xml
<dependency>
    <groupId>org.springframework.session</groupId>
    <artifactId>spring-session-data-redis</artifactId>
</dependency>

// application.yml
spring:
  session:
    store-type: redis
  redis:
    host: redis-cluster-host
    port: 6379

Watch out: objects stored in session must implement Serializable. Check your user info objects — they’re the most common offender.

Effort: 2–5 days (including testing)

2.2 Local File Storage Migration

Problem: uploaded files, generated reports, exported spreadsheets all live on the local disk. Instance A uploads a file; Instance B can’t find it.

Fix: route all file I/O through object storage (MinIO for self-hosted, OSS/S3 on cloud).

// Before: direct local path
File file = new File("/data/uploads/" + filename);
FileUtils.copyInputStreamToFile(inputStream, file);

// After: unified storage service
storageService.upload(inputStream, filename);  // delegates to MinIO/OSS
String url = storageService.getUrl(filename);

Audit tip: search the codebase for new File(, FileInputStream, FileOutputStream, MultipartFile.transferTo — every hit is a candidate for migration.

Effort: 3–7 days (depends on how scattered file operations are)

2.3 Scheduled Job Deduplication

Problem: every instance runs every scheduled job. Three instances running the nightly reconciliation job simultaneously means triple processing and triple notifications.

Fix (pick one based on complexity):

Option A — Distributed lock (simple tasks, low job count):

@Scheduled(cron = "0 0 1 * * ?")
public void dailySettlement() {
    boolean locked = redisLock.tryLock("daily-settlement", 60);
    if (!locked) return;  // another instance already running
    try {
        doSettlement();
    } finally {
        redisLock.unlock("daily-settlement");
    }
}

Option B — Dedicated scheduler (many jobs, complex dependencies): extract scheduled jobs to a single dedicated instance that doesn’t participate in load balancing, or adopt a job scheduling framework (XXL-JOB, Quartz Cluster).

Effort: 3–10 days (depends on job count and business criticality)

2.4 In-Process Cache Migration

Problem: HashMap or Guava LoadingCache caches live in each instance’s memory. After a cache update on Instance A, Instance B still serves stale data.

Fix: replace local caches used for cross-request sharing with Redis. Keep local caches only for data that is truly read-only and process-scoped (e.g., static config loaded at startup).

// Before: local Guava cache
LoadingCache<String, Device> deviceCache = CacheBuilder.newBuilder()
    .expireAfterWrite(5, TimeUnit.MINUTES)
    .build(key -> deviceRepo.findById(key));

// After: Redis-backed, consistent across instances
@Cacheable(value = "device", key = "#deviceId")
public Device getDevice(String deviceId) {
    return deviceRepo.findById(deviceId);
}

Effort: 2–5 days

3. Infrastructure: Load Balancer + Database Read/Write Split

3.1 Nginx Load Balancing

A minimal working config:

upstream app_cluster {
    least_conn;  # route to the instance with fewest active connections
    server 10.0.0.1:8080;
    server 10.0.0.2:8080;
    keepalive 32;
}

server {
    listen 80;
    location / {
        proxy_pass http://app_cluster;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_connect_timeout 5s;
        proxy_read_timeout 60s;
    }
}

Health check: configure Nginx health_check or use a cloud load balancer (ALB/CLB) with active health probes. Remove unhealthy instances from the pool automatically.

Effort: 1–2 days

3.2 Database Read/Write Split

// Route writes to primary, reads to replica via AbstractRoutingDataSource
public class ReadWriteRoutingDataSource extends AbstractRoutingDataSource {
    @Override
    protected Object determineCurrentLookupKey() {
        return TransactionSynchronizationManager.isCurrentTransactionReadOnly()
            ? "replica" : "primary";
    }
}

// Mark read-only transactions explicitly
@Transactional(readOnly = true)
public List<MeterReading> queryReadings(String meterId, LocalDate from, LocalDate to) {
    return meterReadingRepo.findByMeterIdAndDateBetween(meterId, from, to);
}

Effort: 3–5 days

4. Effort Estimation Summary

5. Migration Path: Three Phases

Phase 1 — Stateless First (Weeks 1–3)

Fix all four stateful problems: session, files, scheduled jobs, local cache. Deploy to a test environment and validate thoroughly before touching production.

Phase 2 — Multi-Instance + Load Balancer (Weeks 4–5)

Start with two instances behind Nginx. Validate session sharing, file access, and job deduplication under real traffic. Keep rollback ready.

Phase 3 — Database Read/Write Split (Week 6+)

Set up primary/replica replication. Enable read routing gradually — start with low-risk query-only modules. Monitor replica lag.

6. Common Pitfalls

Don’t skip the stateless audit. The most common failure is deploying multiple instances before fixing session or file storage, then debugging mysterious “random” login failures in production.

Test scheduled jobs with two instances running simultaneously before go-live. A reconciliation job firing twice is a serious data integrity issue.

Replica lag is real. After a write, a subsequent read routed to the replica may return stale data. For operations that read immediately after writing (e.g., “save and display”), force the read to primary.

Microservices are not the next step. After completing this migration, the system handles the vast majority of scaling scenarios most traditional industry platforms will ever face. Microservices introduce distributed transactions, service mesh, independent CI/CD per service, and significant operational overhead. Revisit that decision when the team has grown and the current architecture is a proven bottleneck — not before.

Conclusion

The migration from monolith to distributed deployment is a concrete, achievable project for most traditional industry software teams — typically 4–8 weeks of focused engineering. The payoff is high availability, horizontal scaling, and zero-downtime deploys.

The architecture described here — stateless app nodes, shared Redis, load balancer, primary/replica database — is battle-tested across factory MES, hospital systems, and utility metering platforms. It is not a stepping stone to something else. It is a stable, long-term architecture that most teams can run comfortably for years.

8 - PostgreSQL + TimescaleDB on Huawei Cloud vs Oracle for AMI Projects

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.

Huawei Cloud RDS for PostgreSQL: TimescaleDB Built In

Huawei Cloud RDS for PostgreSQL (versions 12 through 15) ships with TimescaleDB as a built-in plugin. No separate installation, no custom builds, no OS-level access required. Enabling it is a single SQL statement run against your target database:

CREATE EXTENSION IF NOT EXISTS timescaledb;

Huawei Cloud handles the shared_preload_libraries configuration automatically. From that point, you have the full TimescaleDB feature set available inside a fully managed, cloud-native PostgreSQL instance — with automated backups, high availability, and point-in-time recovery included.

Official documentation: Huawei Cloud RDS for PostgreSQL Plugin Overview

Why TimescaleDB Is the Right Engine for AMI Data

Meter reading data has a well-defined shape: a device identifier, a timestamp, and one or more measured values. This pattern repeats billions of times across the life of an AMI deployment. TimescaleDB is purpose-built for exactly this workload.

Hypertables: Automatic Time Partitioning

A TimescaleDB hypertable automatically partitions data into time-based chunks (configurable — e.g., one chunk per week). When a query asks for the last 30 days of readings for a specific meter, the query planner touches only the relevant chunks and skips everything else. On a table with years of history, this is the difference between a millisecond response and a full table scan.

-- Create the meter readings table as a hypertable
CREATE TABLE meter_readings (
    meter_id    TEXT        NOT NULL,
    ts          TIMESTAMPTZ NOT NULL,
    active_kwh  DOUBLE PRECISION,
    reactive_kvarh DOUBLE PRECISION
);

SELECT create_hypertable('meter_readings', 'ts');

Continuous Aggregates: Pre-computed Rollups at Zero Query Cost

TimescaleDB continuous aggregates maintain pre-computed summaries (hourly, daily, monthly totals) that update automatically as new data arrives. Reporting queries that previously required full scans over billions of rows now read from compact aggregate tables.

Compression: 90–95% Storage Reduction on Cold Data

Older chunks — readings from last month, last year — are compressed automatically. TimescaleDB’s columnar compression routinely achieves 90–95% reduction in storage footprint on time-series data. The data remains queryable; compression is transparent to the application.

Oracle in AMI: The Real Costs

Oracle’s licensing model is based on processor cores, with a multiplier applied to physical cores based on the processor type. For a typical AMI deployment running on 4 physical cores:

• Oracle Database Enterprise Edition: ~$47,500 per processor (list price)
• Support and maintenance: 22% of license cost per year
• High Availability (Active Data Guard): additional per-processor license

A modest 4-core primary + 4-core standby deployment routinely exceeds $400,000 USD at list price, before support contracts.

PostgreSQL is open-source. TimescaleDB Community Edition is open-source. Huawei Cloud RDS charges only for compute and storage. The licensing cost delta is not incremental — it is an order of magnitude.

Head-to-Head: TimescaleDB vs Oracle for AMI Workloads

Migration Path from Oracle

A full migration is outside the scope of this document, but the key steps are:

1. Schema conversion: Oracle-specific types (VARCHAR2, NUMBER) map cleanly to PostgreSQL equivalents (TEXT, NUMERIC). Tools like ora2pg automate most of the DDL conversion.
2. Hypertable setup: Identify your primary time-series tables and convert them to hypertables. This is a one-time step that does not require application changes.
3. Continuous aggregate definitions: Replace Oracle materialized views with TimescaleDB continuous aggregates for auto-refreshing rollups.
4. Application layer: PostgreSQL uses standard JDBC/ODBC drivers. Connection string changes are typically the only application modification required.

Conclusion

For AMI deployments, TimescaleDB on Huawei Cloud RDS for PostgreSQL delivers better time-series performance than Oracle at a fraction of the total cost. The hypertable model maps directly to the meter-reading data pattern. Continuous aggregates replace expensive rollup queries. Columnar compression handles the long-tail of historical data efficiently.

Oracle remains a defensible choice for organizations with existing enterprise agreements and Oracle-specific tooling already in place. For new AMI deployments or platforms undergoing architectural modernization, PostgreSQL + TimescaleDB is the technically correct and economically rational choice.

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

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.

The Cloud Way: Distributed Architecture and Load Balancing

Moving to public cloud is not just about swapping physical servers for virtual ones. The real transformation is architectural: from a monolithic single-node design to a distributed multi-node setup with load balancing.

In a distributed architecture, incoming traffic is spread across multiple application nodes by a load balancer. No single node carries the full load. When business volume increases, new nodes are added to the pool — without shutting anything down. Users experience no interruption.

Traditional Architecture
─────────────────────────
  [Primary Server]  ←→  [Standby Server]
       ↑
  All traffic hits one machine.
  Upgrade = shutdown + hardware swap.

Cloud-Native Architecture
─────────────────────────
         [Load Balancer]
        /       |       \
  [Node 1]  [Node 2]  [Node 3]  ...  [Node N]
       ↑
  Traffic distributed across nodes.
  Scale out = add nodes, zero downtime.

Why This Matters for Gurux.DLMS.AMI

Gurux.DLMS.AMI is a platform for managing DLMS/COSEM devices at scale. As the number of connected meters and devices grows, the system must handle increasing read/write throughput, concurrent connections, and data processing load.

A monolithic deployment on a single server creates a hard ceiling. When that ceiling is hit, the only path forward is downtime-based vertical scaling — and eventually, you run out of hardware headroom entirely.

A distributed deployment removes that ceiling. The AMI backend, message processing, and API layers can each be scaled independently by adding nodes. The load balancer routes requests to healthy, available instances. Capacity grows with demand, not against it.

Key Principles for the Migration

1. Stateless application nodes Each node should be able to handle any request without relying on local state. Session data, caches, and queues belong in shared infrastructure (Redis, a message broker), not on individual nodes.

2. A single load balancer entry point All external traffic enters through the load balancer. Nodes are added or removed from the pool without changing client configuration.

3. Shared, replicated data layer The database must be accessible from all nodes. Use managed cloud database services with replication to avoid the data layer becoming a single point of failure.

4. Health checks and graceful handling The load balancer should continuously probe node health. Unhealthy nodes are removed from rotation automatically, and traffic is redistributed to the remaining nodes.

The Bottom Line

The shift from physical servers to cloud is not just an infrastructure change — it is an architectural one. The traditional primary/standby model was designed around hardware constraints that no longer apply in the cloud. Distributed multi-node architecture with load balancing is the correct model for cloud deployment: it eliminates forced downtime for capacity changes and lets the system grow smoothly as demand increases.

For a platform like Gurux.DLMS.AMI, where device counts and data volumes grow continuously, this architectural foundation is not optional — it is the prerequisite for sustainable operation at scale.