DEV · DEVOPS · API-FIRST

Cloud that
devs love · DevOps trusts

OpenStack API · Terraform · K8s · Git deploy · CI/CD · logs/metrics/APM · pay-as-you-go · 60-second VM spin-up · senior devs you can talk to directly.

Start free →See pillars

API-first Terraform ready<60s VM spin-upK8s Managed 1.29

OpenStack API · IaC Terraform · Ansible · OpenStack CLI

Managed Kubernetes 1.29 auto-scale · LB · Ingress · Helm

Git Deploy · CI/CD push-to-deploy · preview branches

<60s · Spin-up VM, DB, K8s cluster instant

Logs · Metrics · APM Loki · Prometheus · OTel

Pay-as-you-go · ฿ per-second billing · free tier

01 / PRODUCTION, WITH CONTEXT

Every deploy, traceable.
Every incident, in context.

Let’s talk architecture, pull requests and telemetry. Build a platform your team can understand, inspect and operate.

Explore the engineering stack

IaC / GitOps / Kubernetes / OpenTelemetry

platform / productionREFERENCE

⑂ maindesired state → reconcile

$ git diff --stat
infra/ workloads/ policies/

Git repositoryreviewed · versioned

⑈ workload clusterRECONCILE

api

worker

gateway

commit → release → telemetry

Illustrative workflow for architecture discussion

01 / ENGINEERING OUTPUT

Reviewable infrastructure

Architecture, IaC and a reviewable change history.

02 / ENGINEERING OUTPUT

Actionable telemetry

Connect system behaviour to a service, release and owner.

03 / ENGINEERING OUTPUT

Operable handover

Runbooks, an access matrix and an actionable recovery plan.

02 / INFRASTRUCTURE AS CODE

Infrastructure you can read like code.

Start with the resource model and dependency graph, then choose the tooling: Terraform, OpenStack APIs or Kubernetes manifests.

platform-repo / examples

# Reference plan · review before apply
  + module.network
      private_subnet
      security_group

  + module.compute
      api_pool
      worker_pool

  ~ module.observability
      retention_policy

# Review gates
# [ ] state isolation & backend locking
# [ ] provider / resource compatibility
# [ ] quota, cost & destructive changes

# Illustrative pod-spec fragment
# Tune paths and resources per workload
containers:
  - name: api
    resources:
      requests: {cpu: "250m", memory: "256Mi"}
      limits: {memory: "512Mi"}
    startupProbe:
      httpGet: {path: /health/startup, port: 8080}
      failureThreshold: 30
      periodSeconds: 10
    readinessProbe:
      httpGet: {path: /health/ready, port: 8080}
      periodSeconds: 5
# Not a complete deployable manifest

# api / elevated-error-rate

## Triage
1. Check SLO burn rate & recent releases
2. Correlate trace_id with logs
3. Inspect downstream saturation

## Mitigation
- Route to the named incident owner
- Revert desired state when appropriate
- Validate database compatibility first

## Verify & follow up
- Confirm user-facing recovery
- Record timeline and action owners

State is a security boundary

Isolate environments and remote-state access. Choose a backend with locking and recovery; keep credentials out of the repository.

Plan → review → apply

Review destructive changes, quotas and cost before apply. Define approval gates and a pull-request workflow for drift.

Portable by design

Separate modules from environment configuration. Check actual provider and resource compatibility to estimate migration effort.

Explore Cloud IaaS and service scope

03 / DELIVERY & ORCHESTRATION

Ship through pipelines.
Control production with policy.

Design CI for traceable artifacts and CD for controlled changes to desired state. Fit the toolchain to the team you already have.

delivery.yamlREFERENCE PIPELINE

01CommitPR · review · tests
02Buildimage · scan · SBOM
03Publishregistry · image digest
04ReconcileGitOps · approval policy
05Verifyhealth · SLO · rollout

immutable artifact → declarative state → observable release

Kubernetes, beyond “Running”

Match requests, limits, readiness and startup probes to application behaviour. Choose appropriate HPA metrics, separately from worker-node scaling.

PDBs constrain voluntary eviction, not Deployment rolling updates. Define the rollout strategy separately.

Explore Managed Kubernetes

Rollback ≠ database rollback

Git revert→desired state→reconcile

Choose rolling, canary or blue-green delivery to fit the architecture. Define rollout stop conditions from health and telemetry. A Git revert does not reverse database changes.

Use backward-compatible migrations or expand–contract, with a backup and restore plan before schema changes.

Toolchain, delivery strategy and HA topology depend on project scope and service capabilities

04 / OBSERVABILITY

From symptom
to dependency.

Go beyond high CPU. Correlate metrics, logs and distributed traces to locate a slow request, its user impact and the release involved.

OpenTelemetry
instrument · correlate · export

service / checkout-apiILLUSTRATIVE TELEMETRY

REQUEST RATE1.2kreq/s

P95 LATENCY184ms

ERROR RATIO0.08%

DECISION SIGNALSLOburn rate

error budget → alert → runbook

TRACE WATERFALL0 → 184 ms

POST /checkout starts at approximately 0 milliseconds, duration 184 milliseconds

auth.verify starts at approximately 7 milliseconds, duration 33 milliseconds

inventory.reserve starts at approximately 42 milliseconds, duration 85 milliseconds

db.query starts at approximately 63 milliseconds, duration 53 milliseconds

queue.publish starts at approximately 138 milliseconds, duration 35 milliseconds

LOG CORRELATION

trace_id = 7f3a…2c91
service = checkout-api
release = commit:8b7c21a
span = inventory.reserve

One context.
Connected signals.

Screen values are illustrative, not benchmarks or live system status

Signals with context

Propagate trace context between services and include trace IDs in logs. Plan sampling and sensitive-data handling.

SLO-driven alerting

Choose user-facing SLIs and multi-window error-budget burn alerts. Assign an owner and a runbook.

Telemetry has a budget

Agree retention, metric cardinality and trace sampling before ingestion to manage data volume, cost and investigation windows.

05 / SECURITY AS AN ENGINEERING PRACTICE

Guardrails from build
to runtime.

Make security part of delivery, with explicit access boundaries, tooling and incident response.

IDENTITY

Least privilege, explicit ownership

RBAC, scoped service accounts and secret rotation. Separate human and automation access with an audit trail.

SUPPLY CHAIN

Trust what you deploy

Plan image scanning, SBOMs, provenance and admission policies for the toolchain, including exceptions and approvers.

RUNTIME

Reduce blast radius

Design segmentation and NetworkPolicy with a CNI that enforces it. Add WAF, EASM, pentesting and SOC based on risk.

Ruk-Com Agent covers Technology and Cyber Security within the agreed scope

06 / WORKLOAD BLUEPRINTS

Choose architecture by workload.
Not by VM count.

Use these as starting points for design review, then adapt them to traffic patterns, data lifecycles and failure modes.

BLUEPRINT / 01

IngressAPI replicasData layer

SaaS & API platforms

Separate tenant boundaries, the stateless tier and database connection pools. Plan capacity and recovery per service tier.

Managed Kubernetes

BLUEPRINT / 02

QueueWorkersObject store

Async & data pipelines

Design idempotency, retry/backoff, dead-letter queues and backpressure. Scale workers against queue depth where supported.

Managed Databases

BLUEPRINT / 03

GatewayB300 runtimeModel store

AI inference & GPU

Datacenter and B300 servers are available for AI workloads. Plan model serving, batching, concurrency and GPU memory around the actual model.

GPU Infrastructure

Blueprints are design references, not fixed bundles. Software, licensing, HA and pricing are specified in the proposal

07 / YOUR TEAM + RUK-COM AGENT

Bring production expertise
into your team.

Agree who owns each layer, who handles an incident and what evidence confirms recovery.

Conceptual engineering workspace illustration

YOUR TEAM

Application & domain

Business logic, release decisions, application configuration and the data semantics your team knows best.

RUK-COM AGENT

Platform & operations

Infrastructure, system operations and Cyber Security coordination through agreed services and channels.

SHARED

Change & incident response

RACI, change windows, escalation, recovery exercises and post-incident reviews with action owners.

SLA 99.99%Covered services, measurement and conditions defined in the contract

Before kickoff: agree topology, support scope, RTO/RPO, telemetry retention, pricing and required licences.

08 / BEFORE YOU DEPLOY

Questions worth asking
before production.

The details that turn a design review into an actionable plan.

Can we keep our existing toolchain?

Start with your existing Git, CI, registry and observability tools. We review integrations and required access, then document shared ownership in the proposal. You do not need to replace everything at once.

What does Managed Kubernetes cover?

We define responsibility for the control plane, worker nodes, upgrades, backups and incident response before kickoff. Application delivery, secrets and data recovery need explicit owners for the chosen architecture.

Does GitOps rollback also roll back the database?

Not automatically. Restoring desired state requires checking compatibility with the current schema and data. Migration strategy, backup and recovery must be planned separately from application rollout.

How much log and trace data can we ingest?

We scope ingestion volume, retention, cardinality and sampling around your workload, including storage cost and data access. Unlimited retention or ingestion is not assumed.

What should we prepare for an AI workload on B300?

Share the model, framework, expected GPU memory, concurrency, latency target and data characteristics. We scope sizing and a PoC with agreed evaluation criteria.

What do you need for a useful technical proposal?

Share the current architecture, traffic and growth, SLOs, RTO/RPO and security or procurement constraints. We document services, responsibilities, migration and pricing for review before work starts.

Technical references behind the design approach

OpenStack Terraform provider ↗ Argo CD · automated sync ↗ Kubernetes · disruptions & PDB ↗ Kubernetes · HPA ↗ OpenTelemetry · signals ↗ Google SRE · alerting on SLOs ↗

$ start architecture-review

Bring your architecture.
Let’s work through it.

Talk through the happy path and the failure modes with a team covering Technology and Cyber Security.

Talk architecture with our team LINE @rukcom

[email protected]

architecture-review.md

01 Current stack & topology

02 Traffic, SLO & growth

03 Security & data boundaries

04 Scope, timeline & budget