DEV Community: Herbert

Enterprise Best Practice: Single Landing Zone Architecture for Multi-Project Master Accounts - Huawei Cloud

Herbert — Mon, 28 Sep 2026 02:43:50 +0000

Executive Summary & Core Architectural Principle

Core Principle: "Decouple Financial Billing from Governance & Security, Centralize Organizational Control."

In enterprises with multiple projects, each project often maintains its own Project Master Account to handle independent billing, invoicing, and negotiated commercial discounts. However, Security, Network, and Audit teams must maintain a single, consolidated operational boundary.

Strict Anti-Pattern to Avoid: Never allow individual Project Master Accounts to independently run Set up Landing Zone. Doing so fragmentizes security baselines, scatters audit trail logs across multiple isolated landing zones, and prevents centralized threat detection.

Recommended Solution: Deploy a single, enterprise-wide Landing Zone using an independent Management (Governance) Account. The Audit/Security role operates centrally within this single Landing Zone structure, while all Project Master Accounts join as member accounts within designated Workloads OUs—preserving their independent billing and contract status without compromising enterprise security.

Architectural Layout

Step-by-Step Implementation Guide

Step 1: Provision an Independent Governance Management Account

Do not use any existing Project Master Account as the root of the Landing Zone.

Register a dedicated enterprise email (e.g., cloud-landingzone-admin@yourcompany.com).
Create/Designate this account as the Organizations Management Account (Master Account).

Note: This account will solely manage the organization tree, enforce Service Control Policies (SCPs), and delegate administrator privileges. It will not host active business workloads or process project billing.

Step 2: Set Up the Single Landing Zone & Provision the Central Audit Account

Log in to the Management Account created in Step 1, navigate to Resource Governance Center (RGC), and click Set up Landing Zone.

When prompted for the Configure an Audit Account parameter during setup:

Select Create new account (Recommended by Huawei Cloud RGC Best Practices).
Account Name: Input a dedicated name such as Enterprise-Audit-Account.
Email Address: Provide a dedicated security/audit team email (e.g., security-audit@yourcompany.com).
Outcome: RGC will automatically create the dedicated Audit Account under the Security OU and assign it as the Delegated Administrator for centralized auditing services:

CTS (Cloud Trace Service): Aggregates multi-account API operational logs.
Config: Monitors cross-account resource compliance and configuration baselines.
SecMaster (Security Master): Provides centralized enterprise-wide threat detection and posture management.

Step 3: Invite Project Master Accounts into the Landing Zone

Once the Landing Zone setup is complete, onboard your existing Project Master Accounts:

From the Management Account, navigate to Organizations and send an organization invitation to Project Master Account A, Project Master Account B, etc.
Log in to each Project Master Account, accept the invitation, and move the accounts under the designated Workloads OU in RGC.
Financial Isolation Integrity: Joining the central Landing Zone organization tree does not alter the underlying enterprise financial relationships (Enterprise Center / Payer-Payee links). Each Project Master Account continues to settle its own bills, receive separate invoices, and retain its unique contractual discounts.

Step 4: Enable Centralized Cross-Account Audit & Control

With all Project Master Accounts enrolled in the single Landing Zone:

Organization-Level Log Aggregation (CTS): RGC automatically configures organization trails. All operational logs from Project Master Accounts A/B and their underlying sub-accounts are automatically streamed to the central Audit Account's OBS buckets. Project admins are restricted by SCPs from modifying or deleting these audit feeds.
Delegated Security Administration: The Security/Audit team logs into the single Audit Account to inspect compliance, view global asset inventories, and respond to security alerts across all projects simultaneously.

Official Huawei Cloud References & Documentation

Landing Zone Setup Procedure (RGC User Guide):

Huawei Cloud RGC - Setting Up a Landing Zone

Refer to the section "Configure an audit account" for parameter specifications.

Multi-Account Governance & Architecture (Cloud Adoption Framework - CAF):

Huawei Cloud CAF - Organization and Account Design

Covers structural isolation of Security/Audit accounts from business workloads.

Unified Compliance & Centralized Auditing (CAF):

Huawei Cloud CAF - Unified Multi-account Management

*Explains delegated administrator roles and organization-wide logging aggregation.

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

Herbert — Tue, 15 Sep 2026 12:49:22 +0000

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

Author: seagaruda | Published: 2026-07-31

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.

Metric	Physical Server (RAID 10, 15K SAS)	Cloud EVS (General Purpose SSD)	Cloud EVS (Ultra-high I/O SSD)
Max IOPS	2,000+ (uncapped)	20,000	128,000
Max Throughput	1–4 GB/s	250 MB/s	1,000 MB/s
Latency	2–8 ms	1–2 ms	0.3–0.5 ms
IOPS provisioning	None	Per-disk cap	Per-disk cap

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

Task	Effort	Description
AWR capture & analysis	2–3 person-days	Capture workload snapshots during peak and batch periods; identify top SQL by elapsed time, I/O, and CPU
SQL inventory & classification	3–5 person-days	Catalog all SQL statements from application code, stored procedures, and reports; classify by criticality
Execution plan review	3–5 person-days	Generate `EXPLAIN PLAN` for top 50–100 SQL; identify full scans, Cartesian joins, inefficient access paths
Infrastructure baseline	1–2 person-days	Document current IOPS, throughput, latency; map to cloud EVS disk type

Subtotal: 9–15 person-days

Optimization Phase

Task	Effort	Description
Index creation & tuning	5–8 person-days	Design and create B-tree, bitmap, and function-based indexes; validate with real query patterns
SQL rewriting	8–15 person-days	Rewrite top-N problematic queries: eliminate full scans, add bind variables, implement pagination
Stored procedure optimization	5–10 person-days	Optimize PL/SQL: BULK COLLECT tuning, FORALL adoption, cursor management
Batch job refactoring	3–7 person-days	Convert row-by-row loops to bulk operations; implement parallelism where appropriate
Partitioning implementation	3–5 person-days	Design partitioning strategy; migrate large tables; build local indexes
Connection pooling setup	1–2 person-days	Configure UCP/HikariCP; tune pool sizes; enable statement caching

Subtotal: 25–47 person-days

Validation & Deployment Phase

Task	Effort	Description
Performance regression testing	3–5 person-days	Re-run all SQL against cloud environment; compare to baseline; document improvements
Load testing	2–3 person-days	Simulate peak load; verify IOPS headroom; identify remaining bottlenecks
Monitoring setup	1–2 person-days	Configure cloud monitoring (Cloud Eye/CloudWatch); set IOPS and latency alerts
Documentation & runbooks	2–3 person-days	Document optimization decisions; create operational runbooks for future tuning

Subtotal: 8–13 person-days

Summary

Phase	Effort (person-days)
Assessment	9 – 15
Optimization	25 – 47
Validation & Deployment	8 – 13
Total	42 – 75 person-days

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:

Consequence	Impact
Over-provisioned cloud storage	Paying for Ultra-high I/O EVS (3–5× the cost of General Purpose SSD) to compensate for bad queries
Slow user experience	Productivity loss, user complaints, SLA violations
Batch window overruns	Nightly jobs bleeding into business hours, cascading delays
Emergency firefighting	Unplanned optimization under production-down pressure — always more expensive than planned work
Cloud reputation damage	"The cloud is slow" narrative, when the real issue is unoptimized code

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:

IOPS are capped, not unlimited. Full table scans that were tolerable on bare metal become IOPS-eating bottlenecks in the cloud.
Multiblock reads are counted differently. A single Oracle I/O call may consume multiple IOPS on cloud storage, accelerating cap exhaustion.
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

Why Most Enterprise Digitalization Fails — and the Only Way Out

Herbert — Fri, 21 Aug 2026 15:33:22 +0000

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:

Reason	Share of respondents
System is too slow or too complex	58%
The data they need is not in the system	47%
The system does not reflect the actual process	39%

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:

Metric	Elite performers	Low performers	Gap
Deployment frequency	On-demand, multiple per day	Less than once per month	973×
Lead time for changes	Under 1 hour	1 to 6 months	6,570×
Mean time to restore	Under 1 hour	1 week to 1 month	168×

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:

Informatization is the prerequisite for digitalization; digitalization is the prerequisite for intelligence.
When systems are bypassed, data leaves the system and the information layer corrupts.
Traditional procurement models cannot iterate fast enough to close the gaps before workarounds become entrenched.
Public cloud + cloud-native architecture + DevOps is the only infrastructure capable of sustaining continuous iteration.
AI coding tools have raised internal developer productivity to the point where domain-expert employees can outperform external teams on fit-for-purpose software.
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.

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

Herbert — Fri, 21 Aug 2026 15:32:45 +0000

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.

Component	On-Premise Era	Public Cloud Today
Load balancer	Hardware F5, tens of thousands upfront	Cloud LB service, usage-based billing, from a few hundred RMB/month
Application servers	Hardware purchase + hosting fees, fixed cost	ECS/cloud VMs, on-demand, horizontally scalable in minutes
Session/cache layer	Self-hosted Redis, manual ops	Managed Redis, SLA-backed, zero ops overhead
Database	Local or co-located, self-managed backup	Cloud RDS with auto-backup, read replicas, HA built in

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.

Native Vibe-Coding Developer

Herbert — Fri, 14 Aug 2026 01:09:48 +0000

Hi,

I’m Herbert, a software developer with expertise in Vibe-Coding natively

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

Herbert — Thu, 13 Aug 2026 12:49:51 +0000

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