DEV Community: Herbert

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