zhongwei/gh-josiahsiegel-claude-code-marketplace-plugins-salesforce-master

Files

Zhongwei Li e1a84710cd Initial commit

2025-11-30 08:29:16 +08:00

17 KiB

Raw Permalink Blame History

name, description

name	description
hyperforce-2025	Salesforce Hyperforce public cloud infrastructure and architecture (2025)

🚨 CRITICAL GUIDELINES

Windows File Path Requirements

MANDATORY: Always Use Backslashes on Windows for File Paths

When using Edit or Write tools on Windows, you MUST use backslashes (\) in file paths, NOT forward slashes (/).

Examples:

❌ WRONG: D:/repos/project/file.tsx
✅ CORRECT: D:\repos\project\file.tsx

This applies to:

Edit tool file_path parameter
Write tool file_path parameter
All file operations on Windows systems

Documentation Guidelines

NEVER create new documentation files unless explicitly requested by the user.

Priority: Update existing README.md files rather than creating new documentation
Repository cleanliness: Keep repository root clean - only README.md unless user requests otherwise
Style: Documentation should be concise, direct, and professional - avoid AI-generated tone
User preference: Only create additional .md files when user specifically asks for documentation

Salesforce Hyperforce Architecture (2025)

What is Hyperforce?

Hyperforce is Salesforce's next-generation infrastructure architecture built on public cloud platforms (AWS, Azure, Google Cloud). It represents a complete re-architecture of Salesforce from data center-based infrastructure to cloud-native, containerized microservices.

Key Innovation: Infrastructure as code that can be deployed anywhere, giving customers choice, control, and data residency compliance.

Five Architectural Principles

1. Immutable Infrastructure

Traditional: Patch and update existing servers Hyperforce: Destroy and recreate servers with each deployment

Old Architecture:
Server → Patch → Patch → Patch → Configuration Drift

Hyperforce:
Container Image v1 → Deploy
New Code → Build Container Image v2 → Replace v1 with v2
Result: Every deployment is identical, reproducible

Benefits:

No configuration drift
Consistent environments (dev = prod)
Fast rollback (redeploy previous image)
Security patches applied immediately

2. Multi-Availability Zone Design

Architecture:

Region: US-East (Virginia)
├─ Availability Zone A (Data Center 1)
│  ├─ App Servers (Kubernetes pods)
│  ├─ Database Primary
│  └─ Load Balancer
├─ Availability Zone B (Data Center 2)
│  ├─ App Servers (Kubernetes pods)
│  ├─ Database Replica
│  └─ Load Balancer
└─ Availability Zone C (Data Center 3)
   ├─ App Servers (Kubernetes pods)
   ├─ Database Replica
   └─ Load Balancer

Traffic Distribution: Round-robin across all AZs
Failure Handling: If AZ fails, traffic routes to remaining AZs
RTO (Recovery Time Objective): <5 minutes
RPO (Recovery Point Objective): <30 seconds

Impact on Developers:

Higher availability (99.95%+ SLA)
Transparent failover (no code changes)
Regional data residency guaranteed

3. Zero Trust Security

Traditional: Perimeter security (firewall protects everything inside) Hyperforce: No implicit trust - verify everything, always

Zero Trust Model:
├─ Identity Verification (MFA required for all users by 2025)
├─ Device Trust (managed devices only)
├─ Network Segmentation (micro-segmentation between services)
├─ Least Privilege Access (minimal permissions by default)
├─ Continuous Monitoring (real-time threat detection)
└─ Encryption Everywhere (TLS 1.3, data at rest encryption)

Code Impact:

// OLD: Assume internal traffic is safe
public without sharing class InternalService {
    // No auth checks - trusted network
}

// HYPERFORCE: Always verify, never trust
public with sharing class InternalService {
    // Always enforce sharing rules
    // Always validate session
    // Always check field-level security

    public List<Account> getAccounts() {
        // WITH SECURITY_ENFORCED prevents data leaks
        return [SELECT Id, Name FROM Account WITH SECURITY_ENFORCED];
    }
}

2025 Requirements:

MFA Mandatory: All users must enable MFA
Session Security: Shorter session timeouts, IP restrictions
API Security: JWT with short expiration (15 minutes)

4. Infrastructure as Code (IaC)

Everything defined as code, version-controlled:

# Hyperforce deployment manifest (conceptual)
apiVersion: hyperforce.salesforce.com/v1
kind: SalesforceOrg
metadata:
  name: production-org
  region: aws-us-east-1
spec:
  edition: enterprise
  features:
    - agentforce
    - dataCloud
    - einstein
  compute:
    pods: 50
    autoScaling:
      min: 10
      max: 100
      targetCPU: 70%
  storage:
    size: 500GB
    replication: 3
  backup:
    frequency: hourly
    retention: 30days
  networking:
    privateLink: enabled
    ipWhitelist:
      - 203.0.113.0/24

Benefits for Developers:

Reproducible: Recreate exact environment anytime
Version Controlled: Track all infrastructure changes in Git
Testable: Validate infrastructure before deployment
Automated: No manual configuration, eliminates human error

5. Clean Slate (No Legacy Constraints)

Hyperforce rebuilt from scratch:

Modern Kubernetes orchestration
Cloud-native services (managed databases, object storage)
API-first design (everything accessible via API)
Microservices architecture (independent scaling)
No legacy code or technical debt

Public Cloud Integration

AWS Hyperforce Architecture

┌────────────────────────────────────────────────────────┐
│                  AWS Region (us-east-1)                │
├────────────────────────────────────────────────────────┤
│  VPC (Virtual Private Cloud)                           │
│  ├─ Public Subnets (3 AZs)                             │
│  │  └─ Application Load Balancer (ALB)                 │
│  ├─ Private Subnets (3 AZs)                            │
│  │  ├─ EKS Cluster (Kubernetes)                        │
│  │  │  ├─ Salesforce App Pods (autoscaling)            │
│  │  │  ├─ Metadata Service Pods                        │
│  │  │  ├─ API Gateway Pods                             │
│  │  │  └─ Background Job Pods (Batch, Scheduled)       │
│  │  ├─ RDS Aurora PostgreSQL (multi-AZ)                │
│  │  ├─ ElastiCache Redis (session storage)             │
│  │  └─ S3 Buckets (attachments, documents)             │
│  └─ Database Subnets (3 AZs)                           │
│     └─ Aurora Database Cluster                         │
├────────────────────────────────────────────────────────┤
│  Additional Services                                   │
│  ├─ CloudWatch (monitoring, logs)                      │
│  ├─ CloudTrail (audit logs)                            │
│  ├─ AWS Shield (DDoS protection)                       │
│  ├─ AWS WAF (web application firewall)                 │
│  ├─ KMS (encryption key management)                    │
│  └─ PrivateLink (secure connectivity)                  │
└────────────────────────────────────────────────────────┘

AWS Services Used:

Compute: EKS (Elastic Kubernetes Service)
Database: Aurora PostgreSQL (multi-master)
Storage: S3 (object storage), EBS (block storage)
Networking: VPC, ALB, Route 53, CloudFront CDN
Security: IAM, KMS, Shield, WAF, Certificate Manager

Azure Hyperforce Architecture

Azure Region (East US)
├─ Virtual Network (VNet)
│  ├─ AKS (Azure Kubernetes Service)
│  │  └─ Salesforce workloads
│  ├─ Azure Database for PostgreSQL (Hyperscale)
│  ├─ Azure Cache for Redis
│  └─ Azure Blob Storage
├─ Azure Front Door (CDN + Load Balancer)
├─ Azure Monitor (logging, metrics)
├─ Azure Active Directory (identity)
└─ Azure Key Vault (secrets, encryption)

Google Cloud Hyperforce Architecture

GCP Region (us-central1)
├─ VPC Network
│  ├─ GKE (Google Kubernetes Engine)
│  ├─ Cloud SQL (PostgreSQL)
│  ├─ Memorystore (Redis)
│  └─ Cloud Storage (GCS)
├─ Cloud Load Balancing
├─ Cloud Armor (DDoS protection)
├─ Cloud Monitoring (Stackdriver)
└─ Cloud KMS (encryption)

Data Residency and Compliance

Geographic Regions (2025)

Available Hyperforce Regions:

Americas:
├─ US East (Virginia) - AWS, Azure
├─ US West (Oregon) - AWS
├─ US Central (Iowa) - GCP
├─ Canada (Toronto) - AWS
└─ Brazil (São Paulo) - AWS

Europe:
├─ UK (London) - AWS
├─ Germany (Frankfurt) - AWS, Azure
├─ France (Paris) - AWS
├─ Ireland (Dublin) - AWS
└─ Switzerland (Zurich) - AWS

Asia Pacific:
├─ Japan (Tokyo) - AWS
├─ Australia (Sydney) - AWS
├─ Singapore - AWS
├─ India (Mumbai) - AWS
└─ South Korea (Seoul) - AWS

Middle East:
└─ UAE (Dubai) - AWS

Data Residency Guarantees

What stays in region:

All customer data (records, attachments, metadata)
Database backups
Transaction logs
Audit logs

What may leave region:

Telemetry data (anonymized performance metrics)
Security threat intelligence
Platform health monitoring

Code Implication:

// Data residency automatically enforced
// No code changes needed - Hyperforce handles it

// Example: File stored in org's region
ContentVersion cv = new ContentVersion(
    Title = 'Customer Contract',
    PathOnClient = 'contract.pdf',
    VersionData = Blob.valueOf('contract data')
);
insert cv;

// File automatically stored in:
// - AWS S3 in org's region
// - Encrypted at rest (AES-256)
// - Replicated across 3 AZs in region
// - Never leaves region boundary

Compliance Certifications

Hyperforce maintains:

SOC 2 Type II: Security, availability, confidentiality
ISO 27001: Information security management
GDPR: EU data protection compliance
HIPAA: Healthcare data protection (BAA available)
PCI DSS: Payment card data security
FedRAMP: US government cloud security (select regions)

Performance Improvements

Latency Reduction

Old Architecture (data center-based):

User (Germany) → Transatlantic cable → US Data Center → Response
Latency: 150-200ms

Hyperforce:

User (Germany) → Frankfurt Hyperforce Region → Response
Latency: 10-30ms

Result: 5-10x faster for regional users

Auto-Scaling

Traditional: Fixed capacity, must provision for peak load Hyperforce: Dynamic scaling based on demand

Business Hours (9 AM - 5 PM):
├─ High user load
├─ Kubernetes scales up pods: 50 → 150
└─ Response times maintained

Off Hours (6 PM - 8 AM):
├─ Low user load
├─ Kubernetes scales down pods: 150 → 30
└─ Cost savings (pay for what you use)

Black Friday (peak event):
├─ Extreme load
├─ Kubernetes scales to maximum: 30 → 500 pods in minutes
└─ No downtime, no performance degradation

Governor Limits - No Change:

// Hyperforce does NOT change governor limits
// Limits remain the same as classic Salesforce:
// - 100 SOQL queries per transaction
// - 150 DML statements
// - 6 MB heap size (sync), 12 MB (async)

// But: Infrastructure scales to handle more concurrent users

Migration to Hyperforce

Migration Process

Salesforce handles migration (no customer action required):

Phase 1: Assessment (Salesforce internal)
├─ Analyze org size, customizations
├─ Identify any incompatible features
└─ Plan migration window

Phase 2: Pre-Migration (Customer notified)
├─ Salesforce sends notification (90 days notice)
├─ Customer tests in sandbox (migrated first)
└─ Customer validates functionality

Phase 3: Migration (Weekend maintenance window)
├─ Backup all data
├─ Replicate data to Hyperforce
├─ Cutover DNS (redirect traffic)
└─ Validate migration success

Phase 4: Post-Migration
├─ Monitor performance
├─ Support customer issues
└─ Decommission old infrastructure

Downtime: Typically <2 hours

What Changes for Developers?

No Code Changes Required:

// Your Apex code works identically on Hyperforce
public class MyController {
    public List<Account> getAccounts() {
        return [SELECT Id, Name FROM Account LIMIT 10];
    }
}

// No changes needed
// Same APIs, same limits, same behavior

Potential Performance Improvements:

Faster API responses (lower latency)
Better handling of concurrent users
Improved batch job processing (parallel execution)

Backward Compatibility: 100% compatible with existing code

Testing Pre-Migration

Use Sandbox Migration:

1. Salesforce migrates your sandbox first
2. Test all critical functionality:
   ├─ Custom Apex classes
   ├─ Triggers and workflows
   ├─ Integrations (API callouts)
   ├─ Lightning components
   └─ Reports and dashboards

3. Validate performance:
   ├─ Run load tests
   ├─ Check API response times
   └─ Verify batch jobs complete

4. Report any issues to Salesforce
5. Production migration scheduled after sandbox validated

Hyperforce for Developers

Enhanced APIs

Hyperforce exposes infrastructure APIs:

// Query org's Hyperforce region (API 62.0+)
Organization org = [SELECT Id, InstanceName, InfrastructureRegion__c FROM Organization LIMIT 1];
System.debug('Region: ' + org.InfrastructureRegion__c); // 'aws-us-east-1'

// Check if org is on Hyperforce
System.debug('Is Hyperforce: ' + org.IsHyperforce__c); // true

Private Connectivity

AWS PrivateLink / Azure Private Link:

Traditional: Salesforce API → Public Internet → Your API
Security: TLS encryption, but still public internet

Hyperforce PrivateLink: Salesforce API → Private Network → Your API
Security: Never touches public internet, lower latency

Setup:
1. Create VPC Endpoint (AWS) or Private Endpoint (Azure)
2. Salesforce provides service endpoint name
3. Configure Named Credential in Salesforce with private endpoint
4. API calls route over private network

Configuration:

// Named Credential uses PrivateLink endpoint
// Setup → Named Credentials → External API (PrivateLink)
// URL: https://api.internal.example.com (private endpoint)

// Apex callout
HttpRequest req = new HttpRequest();
req.setEndpoint('callout:ExternalAPIPrivateLink/data');
req.setMethod('GET');

Http http = new Http();
HttpResponse res = http.send(req);

// Callout never leaves private network
// Lower latency, higher security

Monitoring

CloudWatch / Azure Monitor Integration:

Salesforce publishes metrics to your cloud account:
├─ API request volume
├─ API response times
├─ Error rates
├─ Governor limit usage
└─ Batch job completion times

Benefits:
- Unified monitoring (Salesforce + your apps)
- Custom alerting (CloudWatch Alarms)
- Cost attribution (AWS Cost Explorer)

Best Practices for Hyperforce

Security

Enable MFA: Required for all users in 2025
Use WITH SECURITY_ENFORCED: Field-level security in SOQL
Implement IP whitelisting: Restrict access to known IPs
Monitor audit logs: Setup → Event Monitoring
Rotate credentials: API keys, certificates, passwords regularly

Performance

Leverage caching: Platform Cache for frequently accessed data
Optimize queries: Use indexed fields, selective queries
Async processing: Use @future, Queueable for non-critical work
Bulkification: Always design for 200+ records
Monitor limits: Use Limits class to track governor limit usage

Data Residency

Understand requirements: Know your compliance obligations
Choose correct region: Select region meeting your needs
Validate configurations: Ensure integrations respect boundaries
Document decisions: Maintain records of data residency choices

Cost Optimization

Right-size storage: Archive old data, delete unnecessary records
Optimize API calls: Batch API calls, use composite APIs
Schedule batch jobs efficiently: Run during off-peak hours
Monitor usage: Track API calls, storage, compute usage

Resources

Hyperforce Trust Site: https://trust.salesforce.com/en/infrastructure/hyperforce/
Hyperforce FAQ: Salesforce Help documentation
Available Regions: https://help.salesforce.com/s/articleView?id=sf.getstart_domain_overview.htm
Migration Guide: Provided by Salesforce 90 days before migration
Trust & Compliance: https://compliance.salesforce.com/

Future Roadmap (2025+)

Expected Enhancements:

More regions (Africa, additional Asia Pacific)
Bring Your Own Cloud (BYOC) - use your own AWS/Azure account
Multi-region active-active (write to multiple regions simultaneously)
Edge computing (Salesforce at CDN edge locations)
Kubernetes cluster API (direct pod management for enterprises)

Hyperforce represents Salesforce's commitment to modern, cloud-native infrastructure that scales globally while meeting the most stringent compliance and performance requirements.

17 KiB Raw Permalink Blame History