Parent folderOpen Confluence

RWS Architecture article

External Load Balancing

External Load Balancing is the product-neutral architecture building block for external traffic publication, load balancing, and ingress control. It states what DC 3.0 needs from t

  1. Typeabb
  2. Statuscandidate
  3. Domainnetwork
On this page
  1. ABB External Load Balancing
  2. Summary
  3. Capabilities
  4. Constraints
  5. Service Description
  6. Roadmaps
  7. Landing Zones
  8. Interfaces
  9. Dependencies
  10. EIRA Alignment
  11. Available SBB's

ABB External Load Balancing

Summary

External Load Balancing is the product-neutral architecture building block for external traffic publication, load balancing, and ingress control. It states what DC 3.0 needs from this capability before a concrete SBB, product, or operating model is selected.

Capabilities

  • Provides external traffic publication, load balancing, and ingress control.
  • Defines the functional, technical, security, and quality expectations that SBBs must satisfy.
  • Keeps service ownership, interfaces, and consumption boundaries visible before product selection.
  • Enables traceability from architecture intent to implementation, operational evidence, and consuming services.

Constraints

  • The resulting SBB must fit the datacenters ownership model and document the support, lifecycle, and service-management boundary.
  • Security, privacy, logging, evidence, and compliance controls must be explicit enough to assess BIO2-aligned implementation where applicable.
  • Published services must include ownership, certificate, DNS, monitoring, and security-control requirements.
  • The solution must not bypass approved ingress and inspection paths.

Service Description

This ABB offers an external load-balancing service that exposes approved DC 3.0 services through controlled entry points. It is consumed by solution architects, platform teams, and service owners as the capability contract for selecting and shaping SBBs.

The service description remains implementation-neutral: product selection, hosting pattern, detailed runbooks, and service levels belong in the mapped SBB and related ADRs.

Roadmaps

  • Baseline: confirm scope, service ownership, constraints, and acceptance criteria for External Load Balancing.
  • MVP: validate the mapped SBB implementation and record the selected support and lifecycle model.
  • Next: add measurable service levels, evidence requirements, and roadmap dependencies once the SBB is selected.

Landing Zones

  • External cloud or external connectivity zone where services are intentionally published or interconnected.
  • Private cloud and central DC 3.0 landing zone for core infrastructure and platform services.
  • Government cloud or external cloud landing zones only when the SBB documents the required control set, connectivity model, and data classification fit.

Interfaces

  • HTTP, TLS, TCP, and UDP publication interfaces as required.
  • DNS and certificate-management integrations.
  • Telemetry, health-check, and automation APIs.

Dependencies

  • Depends on external-dns for a supporting capability or integration boundary.
  • Depends on public-key-infrastructure for a supporting capability or integration boundary.
  • Depends on dc-network-structure for a supporting capability or integration boundary.
  • Implemented by netscaler-blx as currently mapped SBB traceability.
  • Consuming ABB and SBB dependencies must be recorded as links when solution design identifies concrete upstream or downstream use.

EIRA Alignment

Available SBB's

  • netscaler-blx - NetScaler BLX is a candidate solution building block for the translated DC 3.0 ABB model. It remains candidate until the responsible architects confirm service ownership, support model, and acceptance criteria.