Run

​

Overview

• Automatic scaling based on load
• High availability with multiple replicas
• Environment isolation (dev, staging, test, UAT)
• API gateway through Azure API Management (APIM) to publish, secure, and monitor connector APIs
• Service mesh integration for secure communication

​

Environments

​

Environment access

team_members = {
  "developer@example.com" = {
    grandcentral = {
      roles = [
        "dev-rw",      # Full access to dev runtime
        "stg-ro",      # Read-only access to staging
        "test-rw"      # Full access to test environment
      ]
    }
  }
}

• {env}-rw: Full access (read-write) to the environment
• {env}-ro: Read-only access to the environment
• {env}-apim-rw: API Management contributor access
• {env}-apim-ro: API Management reader access
• {env}-apim-subs-ro: Reader access to subscriptions, including primary and secondary keys
• {env}-apim-subs-rw: Subscription management access
• {env}-apim-cred-manager: Credential manager access

​

Accessing Azure resources

​

Azure portal access

1. Navigate to Azure Portal
2. Sign in with your Azure AD credentials
3. Select your subscription/resource group
4. Access resources like:
   • Kubernetes clusters
   • API Management instances
   • Storage accounts
   • Key Vaults

​

Set up kubectl for Azure

# Install Azure CLI (if not installed)
# macOS: brew install azure-cli
# Windows: Download from https://aka.ms/installazurecliwindows
# Linux: https://docs.microsoft.com/en-us/cli/azure/install-azure-cli

# Login to Azure
az login

# Get credentials for your cluster
az aks get-credentials --resource-group <resource-group> --name <cluster-name>

# Verify connection
kubectl get nodes

• Azure CLI Installation
• Azure AKS Documentation
• kubectl Installation

​

Deployment process

​

Applications-live repository

​

Access requirements

• GitHub team membership: applications-live team
• Runtime access: Appropriate Banking OS roles

​

Deployment namespace

​

Namespaces the platform manages

• Network policy enforcement: On hardened runtimes, the policy isolates the namespace from every other namespace.
• infra-resources support: You can enable PostgreSQL databases, Redis caches, and blob storage for the namespace.
• An Azure managed identity and a Kubernetes service account: The platform creates these when you enable one of those shared resources.
• Sync Hub connectivity: On installations that have Sync Hub enabled, the network policy allows workloads labeled as Sync Hub producers to reach the Sync Hub services. Those services publish to Azure Service Bus. For more information, see Sync Hub.
• Istio configuration that you manage: You set this in runtimes/{runtime}/istio/values.yaml in applications-live.

​

Choose a namespace

• Network isolation: From test onward, a NetworkPolicy permits traffic inside each namespace and denies traffic across namespace boundaries. Workloads that share a namespace can reach each other. No other namespace can reach workloads in your namespace. Backbase manages these policies through platform infrastructure as code. You cannot change them from applications-live. To open a boundary between two namespaces, raise a Service Desk request.
• Policy scope: Istio objects, such as AuthorizationPolicy, PeerAuthentication, and egress ServiceEntry and VirtualService, are namespace-scoped. You configure them in runtimes/{runtime}/istio/values.yaml in applications-live. In a dedicated namespace, the rules you write apply only to your own workloads.
• Secret scope: Kubernetes secrets are namespace-scoped. A service account can mount secrets only in its own namespace. When a namespace enables a shared platform resource in infra-resources/resources.yaml, the platform creates an Azure managed identity and a Kubernetes service account for it. Workloads in separate namespaces then do not share database or cache credentials.
• Observability: The namespace is a standard label on platform logs and metrics. You can scope queries, dashboards, and alerts to a single domain when you debug. For more information, see Monitor.
• Resource names: Kubernetes resource names have to be unique only within a namespace. In a dedicated namespace, your release, service, and ConfigMap names can’t collide with names from another domain.

​

Request a namespace

​

Deployment workflow

​

Prepare your connector

• ✅ Built successfully
• ✅ Tested locally
• ✅ Merged to main branch
• ✅ Version tagged

​

Configure runtime settings

​

Create deployment pull request

1. Create a branch in applications-live repository
2. Add or update connector configuration
3. Follow PR title format: feat(GC-123): Deploy my-custom-connector to dev
4. Create Pull Request targeting main branch

​

Review and approve

• Default reviewers: All applications-live team members are automatically assigned
• Custom reviewers: Can be configured per runtime in self-service.tfvars
• Auto-approval: Available for specific runtimes (e.g., dev)

​

Deployment execution

1. Pipeline validates configuration
2. Connector is deployed to Kubernetes
3. Health checks verify successful deployment
4. Connector becomes available in the target environment

​

Promote to a higher runtime

1. Confirm the version works in the lower runtime.
2. Open a pull request that sets the same chart targetRevision and values in runtimes/{next-runtime}/apps and runtimes/{next-runtime}/values. If the API changed, add the APIM entries too.
3. Get review. By default, members of the applications-live team are the reviewers. You can set runtime-specific reviewers with runtime_codeowners_override.
4. Merge the pull request. ArgoCD syncs the change.
5. Verify the connector with an API call.

• Don’t run a later chart version in a higher runtime than in lower runtimes.
• Runtimes vary per installation. Common sets are dev, stg, and prd, or dev, stg, test, and uat.
• If you want a bot to approve pull requests for a runtime such as dev, set auto_approve_runtimes. You can’t combine it with runtime_codeowners_override.

​

Runtime configuration

​

Environment variables

env:
  # API Configuration
  - name: API_BASE_URL
    value: "https://api.example.com"
  
  # Authentication
  - name: API_KEY
    valueFrom:
      secretKeyRef:
        name: connector-secrets
        key: api-key
  
  # Logging
  - name: LOG_LEVEL
    value: "INFO"
  
  # Performance
  - name: CONNECTION_POOL_SIZE
    value: "10"

​

Secrets management

• GitHub Secrets: Managed in self-service repository
• Kubernetes Secrets: Injected at runtime
• Azure Key Vault: For production secrets

​

Resource limits

resources:
  requests:
    memory: "512Mi"    # Minimum memory
    cpu: "500m"        # Minimum CPU
  limits:
    memory: "2Gi"      # Maximum memory
    cpu: "2000m"       # Maximum CPU

​

Container registry

• Customer ACR: GC_CUSTOMER_ACR_BASE_URL (available as GitHub secret)
• Enterprise ACR: GC_ENTERPRISE_ACR_BASE_URL (available as GitHub secret)

• Images are automatically built and pushed during CI/CD
• Use the image reference in your deployment configuration
• Format: <registry>/<image-name>:<tag>

• Access container registry through Azure Portal
• Use Azure CLI: az acr repository list --name <registry-name>
• Azure Container Registry Documentation

​

API management integration

​

APIM access

• {env}-apim-ro: Read API definitions and subscriptions
• {env}-apim-rw: Create and modify APIs
• {env}-apim-subs-rw: Manage subscriptions and keys
• {env}-apim-cred-manager: Manage OAuth credentials

​

Publish your API

1. Access APIM Portal for your environment
2. Create or import API definition
3. Configure backend to point to your connector
4. Set up policies (rate limiting, authentication, etc.)
5. Publish API for consumers

• Azure API Management Documentation
• APIM Policies Reference

​

Subscription management

• Create subscriptions for API consumers
• Manage keys (primary and secondary)
• Rotate keys for security
• Monitor usage through APIM analytics

​

Scaling and performance

​

Horizontal scaling

• CPU utilization
• Memory usage
• Request queue length
• Custom metrics

​

Manual scaling

replicas: 3  # Number of connector instances

​

Performance tuning

• Connection pooling: Configure pool sizes
• Threading: Adjust thread pool configurations
• Caching: Implement caching strategies
• Batch processing: Process messages in batches

​

Health checks and readiness

​

Health endpoints

• Liveness: /health/live - Is the connector running?
• Readiness: /health/ready - Is the connector ready to serve traffic?

​

Monitoring health

• Restart unhealthy pods
• Route traffic only to ready instances
• Prevent deployment of unhealthy versions

​

Rolling updates and rollbacks

​

Rolling updates

1. New pods are created with updated image
2. Traffic gradually shifts to new pods
3. Old pods terminate after traffic migration
4. Zero-downtime deployment achieved

​

Rollback process

1. Identify problematic version
2. Revert configuration in applications-live
3. Create PR to rollback
4. Merge PR to trigger rollback deployment

​

Environment-specific deployments

​

Development environment

• Purpose: Active development and testing
• Access: Developers with dev-rw role
• Deployment: Frequent, often auto-approved
• Configuration: Development API endpoints

​

Staging environment

• Purpose: Integration testing
• Access: QA teams with stg-rw role
• Deployment: Before production releases
• Configuration: Staging API endpoints

​

Test environment

• Purpose: System and performance testing
• Access: Test teams with test-rw role
• Deployment: For comprehensive testing
• Configuration: Test API endpoints

​

UAT environment

• Purpose: User acceptance testing
• Access: Business users with uat-rw role
• Deployment: Pre-production validation
• Configuration: Production-like settings

​

Troubleshooting

​

Deployment failures

• Check: Configuration syntax in applications-live
• Check: Image availability in container registry
• Check: Resource quotas and limits
• Check: Health check endpoints
• Resources: Kubernetes Troubleshooting

• Check: Application logs in DataDog or Grafana
• Check: Environment variables and secrets
• Check: External API connectivity
• Check: Resource limits (memory/CPU)

​

Runtime issues

• Check: External API response times
• Check: Resource constraints
• Check: Network connectivity
• Check: Connection pool settings

• Check: Resource limits and requests
• Check: Memory leaks in code
• Check: Thread pool configurations
• Check: Message queue backlogs

​

Access issues

• Check: Azure login: az login
• Check: Cluster credentials: az aks get-credentials
• Check: Role assignments in Azure Portal
• Check: kubectl configuration: kubectl config view

​

Best practices

1. Start with dev: Deploy to dev environment first
2. Test thoroughly: Validate in staging before production
3. Monitor deployments: Watch logs during and after deployment
4. Use health checks: Implement proper health endpoints
5. Configure resources: Set appropriate resource limits
6. Manage secrets: Never hardcode credentials
7. Version control: Tag and version all deployments
8. Documentation: Document deployment procedures

​

Accessing runtime resources

​

Kubernetes access

# Get connector pods
kubectl get pods -n <namespace>

# View connector logs
kubectl logs -f <pod-name> -n <namespace>

# Describe connector deployment
kubectl describe deployment <connector-name> -n <namespace>

# Get services
kubectl get svc -n <namespace>

# Get ingress
kubectl get ingress -n <namespace>

• kubectl Cheat Sheet
• Kubernetes Documentation

​

Service Bus explorer

• Requires appropriate Azure roles
• Connect via Service Bus Explorer or Azure Portal
• Monitor queues and topics
• Manage subscriptions

• Azure Service Bus Documentation
• Service Bus Explorer GitHub