1. The Problem

The Fintech Reliability Challenge

Intertech — the technology subsidiary of DenizBank/Emirates NBD Group and Turkey’s largest fintech company — processes millions of financial transactions daily. A single minute of downtime means regulatory scrutiny, financial loss, and erosion of customer trust.

Our SRE team’s conviction was clear: every service must prove it can survive failure before it earns the right to run in production. But proving resilience systematically across 1000+ microservices was where things broke down.

Where Existing Tools Fell Short

We adopted LitmusChaos early — a solid chaos experiment engine. But trying to scale it to 1000+ microservices revealed seven distinct layers of complexity that no one tool addressed:

Layer 1 — Experiment Configuration Write 80+ lines of ChaosEngine YAML per experiment — appinfo, serviceAccount, probes, env vars, labels, annotations.

Layer 2 — Service Discovery Manually identify and hardcode applabel, owner team name, SRE team.

Layer 3 — Health Check Integration Find the correct readiness probe endpoint and port, compose the probe URL.

Layer 4 — RBAC Provisioning Create ServiceAccount + Role + RoleBinding per namespace, per experiment.

Layer 5 — Safety Enforcement No mechanism to prevent chaos in kube-system or during low-replica scenarios.

Layer 6 — Observability No unified metrics, no dashboards, no correlation between chaos runs and SLO impact.

Layer 7 — Scheduling & Lifecycle Every test was a manual trigger — no automation, no recurrence, no central control.

The result? Only the SRE team ran chaos tests — and even they did it rarely, because each test required 20–30 minutes of YAML authoring and setup. At 1000+ services, chaos engineering was a good idea we couldn’t operationalize. Even with an operator automating the backend, triggering experiments still required writing YAML and running kubectl — a barrier that kept chaos engineering locked behind terminal expertise.

The Real Cost

This wasn’t just a developer experience problem. It was a resilience coverage gap:

• ~5 services had ever been chaos-tested (out of 1000+)
• Zero services had recurring resilience tests
• Zero correlation between chaos results and production SLOs
• Zero guardrails — nothing prevented chaos in production-critical system namespaces
• Zero automation — every test was a one-off, results tracked in Slack messages
• Zero self-service — QA engineers and developers couldn’t participate without SRE hand-holding

2. Our Solution: A Kubernetes Operator That Solves All Seven Layers

Instead of solving each layer independently, we built a single Kubernetes operator that automates all seven complexity layers behind a declarative CRD — and then topped it with a browser-based QA Testing Interface (Section 9) that lets anyone trigger, monitor, and manage chaos experiments without ever opening a terminal.

The Core Design Principle

The user declares intent. The operator handles everything else.

A developer (or SRE) writes this:

apiVersion: chaos.platform.io/v1alpha1
kind: ChaosExperiment
metadata:
  name: gateway
  namespace: gateway
spec:
  experiments:
    - type: pod-failure
    - type: network-loss

That’s the entire input. No service discovery. No RBAC. No probe URLs. No template authoring. The operator resolves all seven layers automatically.

What the Operator Does Behind the Scenes

Developer Input (3 lines of config)
         │
         ▼
┌─────────────────────────────────────────────────────┐
│           CHAOS PLATFORM CONTROLLER                  │
│                                                      │
│  Layer 1 ✓  Experiment Registry → sensible defaults  │
│  Layer 2 ✓  Deployment labels → owner, SRE team      │
│  Layer 3 ✓  ReadinessProbe → health check URL        │
│  Layer 4 ✓  Auto-create SA + Role + RoleBinding      │
│  Layer 5 ✓  Kill switch, min replica, forbidden NS   │
│  Layer 6 ✓  Prometheus metrics + Grafana dashboards  │
│  Layer 7 ✓  Cron schedule + global defaults          │
│                                                      │
│  Output: Fully configured Litmus ChaosEngine(s)      │
└──────────────────────┬──────────────────────────────┘
                       ▼
              LitmusChaos Engine
              → Runner Pod → Experiment → ChaosResult

Why an Operator, Not Scripts or Helm?

Helm charts — Rejected. Still 30+ lines per values file. No runtime intelligence. No reconciliation.

Shell scripts — Rejected. No state tracking, no retry, no status reporting, fragile.

LitmusChaos GameDay API — Rejected. Good for one-off runs, but no GitOps-friendly CR model, no Kubernetes-native lifecycle.

Custom Kopf Operator ✅ — Chosen. Kubernetes-native CRD. Reconciliation loop. Timer handlers. Status management. Leader election. GitOps compatible.

3. Expected Efficiency

Before building, we calculated the expected return.

Per-Service Time Comparison

Writing a ChaosEngine YAML by hand used to take ~15 minutes. The operator auto-generates it.

Finding service labels and owner info took ~5 minutes per experiment. The operator auto-discovers from Deployment labels.

Locating the correct health check endpoint took ~5 minutes. The operator auto-detects from the readiness probe.

Creating RBAC resources took ~5 minutes. The operator auto-provisions ServiceAccount, Role, and RoleBinding idempotently.

Verifying safety guardrails (namespace allowlist, minimum replica count) took ~3 minutes of manual review. The operator enforces these automatically.

Total per experiment: ~33 minutes → ~1 minute (write a 3-line YAML, apply).

Scale Impact

• Time per experiment setup: ~33 min → ~1 min — 97% reduction
• Services with chaos coverage: 5 → 1000+ potential — 200× increase
• Recurring automated tests: 0 → unlimited (via cron) — ∞
• Manual YAML lines per test: 80+ → 3–96% reduction
• RBAC setup per namespace: manual → automatic — eliminated
• Safety incidents possible: yes → no (kill switch + guardrails) — eliminated

4. Implementation

4.1 Architecture

┌─────────────────────────────────────────────────────────────────────────┐
│                     KUBERNETES CLUSTER (GKE/Anthos)                     │
│                                                                         │
│  ┌───────────────────────────────────────────────────────────────────┐  │
│  │        CHAOS PLATFORM CONTROLLER (Python 3.13 / Kopf 1.36)        │  │
│  │        2 replicas — Leader Election — HA                          │  │
│  │                                                                   │  │
│  │  on.create/update  →  Reconcile ChaosExperiment CR                │  │
│  │  timer(60s)        →  Poll ChaosResults, update status            │  │
│  │  timer(60s)        →  Check cron schedule, trigger experiments    │  │
│  │  timer(120s)       →  Retry blocked experiments                   │  │
│  │  on.delete         →  Cleanup engines, runners, results           │  │
│  │  on.resume         →  Re-process Running experiments on restart   │  │
│  └───────────────────────────────────────────────────────────────────┘  │
│                          │                                              │
│           ┌──────────────┼───────────────┐                              │
│           ▼              ▼               ▼                              │
│  ┌──────────────┐ ┌───────────┐ ┌───────────────┐                       │
│  │ LitmusChaos  │ │Prometheus │ │    Kyverno    │                       │
│  │ ChaosEngine  │ │ 6 metrics │ │   Policies    │                       │
│  │ Runner Pods  │ │ 10 alerts │ │ Forbidden NS  │                       │
│  │ ChaosResult  │ │ 2 dashbds │ │Required Labels│                       │
│  └──────────────┘ └───────────┘ └───────────────┘                       │
└─────────────────────────────────────────────────────────────────────────┘

4.2 The Seven Layers — How Each Is Solved

Layer 1: Experiment Registry — Sensible Defaults

Every experiment type maps to a Litmus experiment, a Jinja2 template, and production-tested defaults:

EXPERIMENT_REGISTRY = {
    "pod-failure": {
        "litmus_name": "pod-delete",
        "template": "pod-failure/base.yaml",
        "defaults": {
            "duration": "60",
            "pods_affected_perc": "50",  # Never kill 100% — learned from production
            "force": "false",
        },
    },
    "network-loss": {
        "litmus_name": "pod-network-loss",
        "template": "network-loss/base.yaml",
        "defaults": {
            "duration": "60",
            "packet_loss_perc": "30",
            "network_interface": "eth0",
        },
    },
    # 6 experiment types total: cpu-stress, memory-stress, pod-failure,
    # pod-kill, network-loss, network-failure
}

The pods_affected_perc: "50" default was a deliberate lesson from production — our first test killed 100% of pods and caused a complete outage. Now half the pods stay alive to serve traffic while the other half are tested.

Layer 2: Automatic Service Discovery

The operator reads Deployment labels — no user input needed:

python

def detect_service_info(namespace, cr_name):
    deployments = apps_api.list_namespaced_deployment(namespace)
    target = _find_target_deployment(deployments, cr_name)
    labels = target.metadata.labels or {}
    return {
        "owner": labels.get("owner", "unknown"),
        "sre_team": labels.get("sreTeamName", "unknown"),
        "app_label": _detect_app_label(target),  # app= or microServiceName=
    }

The CR name matches the Deployment name. Owner and SRE team come from standard labels that already exist on every Intertech deployment.

Layer 3: Automatic Health Check Detection

The operator reads readinessProbe from the target Deployment and constructs the health check URL:

def detect_health_check_url(namespace, service_name):
    for container in target_deploy.spec.template.spec.containers:
        probe = container.readiness_probe or container.liveness_probe
        if probe and probe.http_get:
            path = probe.http_get.path or "/health"
            port = probe.http_get.port or service_port
            return f"http://{service_name}.{namespace}.svc.cluster.local:{port}{path}"

This URL becomes a continuous HTTP probe during the experiment — if the health check fails, the experiment verdict is Fail.

Layer 4: Dynamic RBAC

Every target namespace needs a ServiceAccount + Role + RoleBinding for Litmus. The operator creates these idempotently — no manual setup:

def ensure_chaos_service_account(namespace):
    sa_name = f"{namespace}-chaos-sa"
    # Create SA → Role (minimum permissions) → RoleBinding
    # All idempotent — safe to call multiple times

Layer 5: Safety Guardrails (Defense in Depth)

Five independent safety mechanisms — any one can stop an experiment:

• Kill Switch — a ConfigMap named chaos-operator-kill-switch. Set enabled: "false" to stop ALL chaos instantly across the cluster.
• Forbidden Namespaces — kube-system, istio-system, chaosplatform, and others. Hardcoded in the operator and enforced again by a Kyverno policy for defense in depth.
• Min Replica Check — destructive experiments are blocked if the target Deployment has fewer than 2 replicas.
• Concurrent Limit — no more than 5 experiments can run simultaneously cluster-wide.
• Phased Execution — non-destructive tests (cpu-stress, network-loss) run first. Destructive tests (pod-failure, pod-kill) run only after Phase 1 completes.

Phased Execution deserves special attention. When a CR has both network-loss and pod-failure:

Phase 1 (Non-Destructive)          Phase 2 (Destructive)
┌─────────────────────┐            ┌─────────────────────┐
│  network-loss       │ ──done──▶  │  pod-failure        │
│  cpu-stress         │            │  pod-kill           │
└─────────────────────┘            └─────────────────────┘

This prevents a scenario where pod-failure kills pods while network-loss is still measuring — giving misleading results.

Layer 6: Observability

Six Prometheus metrics with owner/SRE team labels for per-team dashboards:

• chaos_experiment_result_total (Counter) — pass/fail results by service, type, and team.
• chaos_engine_status (Gauge) — currently running engines.
• chaos_operator_errors_total (Counter) — operator errors by type.
• chaos_operator_reconcile_queue_length (Gauge) — reconcile backlog.
• chaos_experiment_start_time (Gauge) — experiment start timestamps.
• chaos_policy_violation_total (Counter) — policy violation attempts.

Plus 10 Prometheus alert rules including SLO breach correlation — detecting if error rate exceeds 5% while a chaos experiment is active.

Layer 7: Scheduling & Global Defaults

The most recent addition — two-tier cron scheduling:

Tier 1 — Operator Global Default:

yaml

# Deployment env var — applies to ALL ChaosExperiments
env:
  - name: DEFAULT_SCHEDULE
    value: "0 14 * * 1-5"    # Weekdays at 14:00 UTC
  - name: DEFAULT_SUSPEND
    value: "false"

Tier 2 — Per-CR Override:

spec:
  schedule: "0 10 * * 1,3"   # This CR: Mon/Wed at 10:00 — overrides global

Priority: CR spec.schedule > Operator DEFAULT_SCHEDULE > None (one-shot)

This means: set one global cron and every CR automatically becomes a recurring test. Any CR can override with its own schedule or opt out.

4.3 Dry-Run Mode

Before running real chaos in production, validate the plan:

yaml

spec:
  dryRun: true
  experiments:
    - type: pod-failure
    - type: network-loss

The operator discovers the service, computes the phased execution plan, and writes everything to status — without creating a single ChaosEngine. Perfect for first-time onboarding.

4.4 High Availability

The operator runs as 2 replicas with Kopf leader election. Only the leader reconciles — if the leader pod dies, the second pod takes over automatically. Running experiments are re-processed via Kopf’s resume handler.

5. Concrete Results

Live Test: gateway/gateway (Network Loss)

Our first production test targeted the gateway service in the gateway namespace:

1. Applied CR: dryRun=true  → phase: DryRun     ✓ Plan validated
2. Applied CR: dryRun=false → phase: Running    ✓ ChaosEngine created
3. Runner pod started       → experiment pod    ✓ Network loss injected
4. Health probe             → continuous check  ✓ Service stayed healthy
5. ChaosResult              → verdict: Pass     ✓ Service survived 30% packet loss
6. CR status                → phase: Completed  ✓ lastResult: Success

Service proved it can handle 30% network packet loss with zero health check failures.

Global Schedule Test

Applied a CR without spec.schedule — operator picked up the global DEFAULT_SCHEDULE:

1. CR applied (no schedule field)  → Operator used DEFAULT_SCHEDULE="*/2 * * * *"
2. Status                          → phase: Scheduled, nextExecution: 2 min later
3. 2 minutes later                 → "Schedule triggered" — experiment ran automatically
4. After completion                → Re-scheduled for next window

Zero configuration in the CR — fully automated by operator-level defaults.

Coverage Impact

• Services with chaos tests: 5 → 30+ (growing weekly)
• Recurring scheduled tests: 0 → all (via global cron)
• Average setup time: ~33 min → under 1 min
• Manual YAML per test: 80+ lines → 3 lines
• Safety incidents: possible → impossible (5-layer guardrails)
• Chaos results in Prometheus: none → every run, labeled by team

6. Adding a New Service — Developer Guide

The Simple Case: Accept All Defaults

A developer wants to add chaos testing for their payment-api service in the payments namespace:

apiVersion: chaos.platform.io/v1alpha1
kind: ChaosExperiment
metadata:
  name: payment-api        # Must match the Deployment name
  namespace: payments      # Target namespace
spec:
  experiments:
    - type: pod-failure

That’s it. Apply with kubectl apply -f and:

• ✅ Operator discovers owner and sreTeamName from Deployment labels
• ✅ Health check URL auto-detected from readiness probe
• ✅ RBAC created automatically in the payments namespace
• ✅ Litmus ChaosEngine rendered with production-tested defaults
• ✅ Results tracked in Prometheus with team labels
• ✅ If global DEFAULT_SCHEDULE is set, it runs on that schedule automatically

Multiple Experiment Types

yaml

spec:
  experiments:
    - type: pod-failure     # Destructive — runs in Phase 2
    - type: network-loss    # Non-destructive — runs in Phase 1
    - type: cpu-stress      # Non-destructive — runs in Phase 1

Operator automatically separates into phases: network-loss + cpu-stress run first, then pod-failure.

Custom Schedule (Override Global)

spec:
  schedule: "0 3 * * 6"    # Saturday 03:00 only — overrides global default
  experiments:
    - type: pod-failure

Validate Before Running (Dry-Run)

spec:
  dryRun: true
  experiments:
    - type: pod-failure
    - type: network-loss

Check the plan: kubectl get chaosexperiment payment-api -n payments -o yaml → status shows exactly what would happen.

Pause Without Deleting

kubectl patch chaosexperiment payment-api -n payments \
  -p '{"spec":{"suspend":true}}' --type=merge

Resume later:

kubectl patch chaosexperiment payment-api -n payments \
  -p '{"spec":{"suspend":false}}' --type=merge

Monitor Results

# All experiments at a glance
kubectl get chaosexperiments -A

# Output:
# NS         NAME          SERVICE       PHASE      SCHEDULE         NEXT RUN
# gateway    gateway       gateway       Scheduled  0 14 * * 1-5     2026-03-31T14:00
# payments   payment-api   payment-api   Completed                   -

7. Supported Experiment Types

• pod-failure — tests pod recovery after graceful deletion. Default impact: 50% of pods, 60 seconds.
• pod-kill — tests pod recovery after force kill. Default impact: 50% of pods, 60 seconds.
• cpu-stress — tests behavior under CPU pressure. Default impact: 1 core, 80% load, 60 seconds.
• memory-stress — tests behavior under memory pressure. Default impact: 128MB allocation, 60 seconds.
• network-loss — tests resilience to packet loss. Default impact: 30% loss, 60 seconds.
• network-failure — tests resilience to severe packet loss. Default impact: 50% loss, 60 seconds.

8. Operational Commands

Stop all chaos (emergency):

kubectl -n chaosplatform patch cm chaos-operator-kill-switch \
  -p '{"data":{"enabled":"false"}}'

Resume after emergency:

kubectl -n chaosplatform patch cm chaos-operator-kill-switch \
  -p '{"data":{"enabled":"true"}}'

Set global schedule:

kubectl -n chaosplatform set env deployment/chaos-operator \
  DEFAULT_SCHEDULE="0 14 * * 1-5"

Pause all schedules:

kubectl -n chaosplatform set env deployment/chaos-operator \
  DEFAULT_SUSPEND="true"

Pause one experiment:

kubectl patch chaosexperiment <name> -n <namespace> \
  -p '{"spec":{"suspend":true}}' --type=merge

View operator logs:

kubectl -n chaosplatform logs deployment/chaos-operator --tail=50

9. QA Testing Interface — Making Chaos Accessible to Everyone

The Last Mile Problem

The operator reduced experiment setup from 33 minutes to 1 minute — but that 1 minute still required:

1. SSH or VPN access to the Kubernetes cluster
2. kubectl installed and configured
3. Knowledge of YAML syntax and CRD schema
4. Terminal literacy to check status, read logs, and debug

For SRE teams, this is fine. For QA engineers, developers, and product teams who need to validate resilience before releases, this was still a barrier. We needed a zero-kubectl, browser-based interface that runs inside the cluster and speaks directly to the Kubernetes API.

Architecture: In-Cluster Real-Time Dashboard

The QA UI runs as a first-class Kubernetes workload in the same chaosplatform namespace as the operator. It is not a static dashboard — it is a live, read-write control plane for ChaosExperiment custom resources.

┌──────────────────────────────────────────────────────────────────────────────┐
│                     KUBERNETES CLUSTER                                       │
│                                                                              │
│  ┌──────────────────────────────────────────┐  ┌──────────────────────────┐  │
│  │   CHAOS PLATFORM CONTROLLER (Kopf)       │  │    QA UI Pod             │  │
│  │   Reconciles ChaosExperiment CRs         │  │  ┌─────────┐ ┌────────┐  │  │
│  │   Creates ChaosEngines                   │◀─│  │ nginx   │ │FastAPI │  │  │
│  │   Monitors ChaosResults                  │  │  │ :80     │ │ :8000  │  │  │
│  │   Updates CR status                      │  │  │ React   │ │ K8s API│  │  │
│  └──────────────────────────────────────────┘  │  │ SPA     │ │ Client │  │  │
│              ▲         ▲                       │  └────┬────┘ └───┬────┘  │  │
│              │         │                       │       │          │       │  │
│     ChaosEngine   ChaosResult                  │       │   REST   │       │  │
│              │         │                       │       └────┬─────┘       │  │
│              │         │                       │            │             │  │
│  ┌───────────┴─────────┴──────┐                │            ▼             │  │
│  │      LitmusChaos           │                │   ServiceAccount RBAC    │  │
│  │      Runner Pods           │                │   (read deployments,     │  │
│  │      Chaos Experiments     │                │    CRUD experiments,     │  │
│  └────────────────────────────┘                │    read kill switch)     │  │
│                                                └──────────────────────────┘  │
│                                                                              │
│  ┌──────────────────────────────────────────────────────────────────────────┐│
│  │ Ingress: chaos-qa.preprod.internal → QA UI Service :80                  ││
│  └──────────────────────────────────────────────────────────────────────────┘│
└──────────────────────────────────────────────────────────────────────────────┘

Key architectural decisions:

• In-cluster deployment: The FastAPI backend uses load_incluster_config() — no kubeconfig files, no credentials stored. The Kubernetes API is accessed via the pod's ServiceAccount token, which is automatically mounted and rotated.
• RBAC-scoped access: A dedicated ClusterRole grants the UI precisely what it needs — CRUD on chaosexperiments, read-only on deployments and namespaces, and read access to the kill switch ConfigMap. Nothing more.
• Two-container pod: nginx serves the React SPA on port 80 and reverse-proxies /api/* to the FastAPI backend on port 8000. No CORS issues in production. One pod, one service, one ingress.
• SQLite for history: Experiment history is persisted to a PVC-backed SQLite database, providing durability across pod restarts without requiring an external database dependency.

What the UI Can Do — Full Lifecycle from a Browser

Every operation that was previously a kubectl command is now a button click:

• List allowed namespaces — kubectl get ns becomes a namespace dropdown auto-filtered to the allowed list.
• List deployments — kubectl get deploy -n gateway becomes a deployment dropdown that shows live replica status.
• Create experiment — kubectl apply -f experiment.yaml becomes "select types → click Run Experiment".
• Delete experiment — kubectl delete chaosexperiment gateway -n gateway becomes a Delete button on the experiment card.
• View experiment status — kubectl get chaosexperiment -o yaml becomes a real-time dashboard with phase badges.
• Suspend schedule — kubectl patch ... suspend=true becomes a Suspend button.
• Emergency stop — the kill-switch patch becomes a kill switch indicator in the header.
• View experiment history — grepping Prometheus or logs becomes a searchable history table with filters and CSV export.

Real-Time Kubernetes Interaction

The UI is not a static page that refreshes on demand. It maintains continuous real-time awareness of the cluster state:

1. 10-second auto-refresh: The frontend polls all active experiments, stats, and kill switch status every 10 seconds. A spinning indicator shows when a refresh cycle is in progress.
2. Live countdown timers: When an experiment is in the Running phase, the dashboard shows a live elapsed-time counter that ticks every second — giving immediate visual feedback that something is happening in the cluster.
3. Phase transition tracking: As the operator reconciles a ChaosExperiment through its lifecycle (Pending → Running → Completed), the UI reflects each transition in real time with color-coded phase badges.
4. Instant deployment discovery: When a QA engineer selects a namespace, the backend queries the Kubernetes API in real time to list deployments with their current replica count. This is not cached — it reflects the live cluster state, so a recently scaled deployment appears immediately.

Creating an Experiment — Zero YAML, Full Power

Here is what a QA engineer sees when creating an experiment through the UI:

Step 1 — Select Target:

• Choose namespace from a filtered dropdown (only allowed namespaces appear)
• Choose deployment from a live-queried list (shows ready/total replica count)
• Pin frequently used deployments for one-click access

Step 2 — Select Experiment Types:

• Six experiment type cards with descriptions and destructive/non-destructive badges
• Multiple selection — the operator handles phased execution automatically
• Phase indicators show which experiments run in Phase 1 vs Phase 2

Step 3 — Configure Options:

• Dry Run toggle: Validate the execution plan without creating any ChaosEngine
• Schedule builder: Visual cron builder with presets (weekdays, daily, weekly) or custom cron input — shows human-readable preview (“Every weekday at 14:00 UTC”)
• Tags: Categorize experiments (sprint-42, team-sre, regression)

Step 4 — Review Execution Plan: A live sidebar shows exactly what will happen:

• Target deployment
• Phase 1 experiments (non-destructive)
• Phase 2 experiments (destructive)
• Safety guardrails that will be enforced
• Mode badges (DRY RUN, SCHEDULED, DESTRUCTIVE)

Step 5 — Confirm and Run:

• Non-destructive experiments run immediately on click
• Destructive experiments trigger a confirmation modal with red warnings
• The backend POSTs to /api/experiments, which calls the Kubernetes API to create the ChaosExperiment CR
• The operator picks it up within seconds and begins reconciliation
• The UI auto-navigates to the Dashboard where the experiment appears in real time

The Confirmation Safety Net

When a QA engineer selects destructive experiment types (pod-failure, pod-kill) without dry-run mode, the UI presents a mandatory confirmation modal:

⚠️ Destructive Experiment

You are about to run destructive chaos experiments on
gateway/gateway. This will affect live pods.
┌─────────────────────────────────┐
│ 💥 Pod Failure                  │
│ ☠️ Pod Kill                     │
└─────────────────────────────────┘
[Cancel]        [Confirm & Run]

This is a deliberate UX decision — the UI should make safe things easy and dangerous things deliberate. Combined with the operator’s five-layer guardrails, it becomes extremely difficult to cause unintended damage.

Dashboard — Live Cluster State

The Dashboard view provides a real-time overview of all experiments across all allowed namespaces:

• Stats bar: Active / Passed / Failed / Scheduled / Total — updated every 10 seconds from Kubernetes
• Experiment cards: Each card shows the experiment name, namespace, phase badge (color-coded and animated for Running), experiment types, creation time, and schedule
• Phase filters: Toggle between All / Active / Completed / Scheduled views
• Global search: Filter experiments by name, namespace, or experiment type across the entire cluster
• Live countdown: Running experiments show elapsed time with a pulsing animation
• Detail modal: Click any experiment card to see full status history, including every phase transition the operator recorded in the CR status

History & Reporting

Every experiment triggered through the UI is recorded in a SQLite database with full metadata — namespace and deployment from the user selection, experiment types from the user selection, phase and result polled from the Kubernetes API, the cron schedule expression, start timestamps and duration, and the trigger source (always “qa-ui” for UI-initiated experiments).

This data powers:

• 14-day timeline chart: Bar chart showing daily experiment activity with success/failure breakdown
• Success rate widget: SVG ring chart showing overall pass rate with per-namespace breakdown
• HTML report generator: One-click downloadable report with stats, charts, and full experiment table
• CSV export: Raw data export for further analysis in Excel or BI tools

Topology View — Cluster-Wide Visibility

The Topology view shows a grid of all allowed namespaces as interactive cards:

• Each card displays the namespace name, deployment count, and active/completed/failed experiment counts
• Color-coded status indicators: green (healthy), amber with pulse animation (experiments running), red (failures)
• Click any namespace to expand and see all experiments in that namespace with phase badges

This gives leadership and SRE managers a single-screen view of chaos engineering coverage across the entire organization.

Templates & Quick Actions — Accelerating Repetitive Work

QA teams often run the same experiments repeatedly — the UI makes this frictionless:

• Save as Template: After configuring an experiment, click “Save Template” to store the full configuration (namespace, deployment, types, schedule, tags) in localStorage
• Template Gallery: Browse saved templates, rename, delete, or instantly load them into the trigger form
• Quick Re-run: The last 6 experiments are shown as one-click cards on the trigger page
• Pinned Deployments: Star frequently tested deployments for instant access across sessions

Bulk Operations — Enterprise Scale

For organization-wide resilience campaigns (e.g., pre-release regression), the Bulk Operations modal allows:

1. Select multiple namespaces at once
2. Select experiment types
3. Choose dry-run mode (recommended for bulk)
4. One click creates experiments across all selected namespaces

The UI reports: “Bulk: 12 experiments created, 0 failed” — each experiment then follows the normal operator reconciliation lifecycle.

Dark/Light Theme & Accessibility

The UI ships with both themes, persisted in localStorage:

• Enterprise White (default): Clean #F8F9FB background, #1E3A5F brand navy, designed for corporate environments and projector presentations
• Dark Mode: #0F1117 background, #60A5FA accent blue, optimized for extended monitoring sessions and SRE war rooms

Toggle with the 🌙/☀️ button in the header or the T keyboard shortcut.

Keyboard Shortcuts — Power User Workflow

For SRE engineers who prefer keyboard-driven workflows:

• 1 – 5 — switch tabs (Trigger → Dashboard → History → Templates → Topology)
• / or Ctrl+K — focus the search bar
• R — refresh all data from Kubernetes
• N — jump to New Experiment (Trigger tab)
• B — open Bulk Operations
• T — toggle theme
• ? — show shortcut help
• Escape — close modals or clear search

All shortcuts are disabled when focus is in an input field.

Mobile Responsive Design

The UI adapts to mobile screens for on-the-go monitoring:

• Header navigation becomes horizontally scrollable
• Stats bar stacks from 5 columns to 2 columns (tablet) to 1 column (phone)
• Experiment cards stack vertically
• Modals stretch to full width
• Touch-friendly button sizes throughout

Deployment Model

The QA UI is deployed as a Kubernetes-native workload:

yaml

# Single Pod — 2 containers
containers:
  - name: frontend     # nginx → React SPA on :80
    image: <internal-registry>/chaosplatform/qa-ui-frontend:latest
  - name: backend      # FastAPI → K8s API client on :8000
    image: <internal-registry>/chaosplatform/qa-ui-backend:latest
    env:
      - name: K8S_IN_CLUSTER
        value: "true"
      - name: ALLOWED_NAMESPACES
        value: "gateway,payments,fraud,identity,lending,notifications,insurance"

# RBAC
ClusterRole: chaosexperiments CRUD, deployments read, configmaps read
ServiceAccount: chaos-qa-ui-sa (namespace: chaosplatform)

# Storage
PVC: 1Gi for SQLite experiment history

# Access
Ingress: chaos-qa.preprod.internal

All container images are built from an internal private registry and pass the standard security pipeline — SAST/SCA analysis, container vulnerability scanning, and image signing — before deployment.

The Impact: From kubectl to Self-Service

• Who can run chaos experiments: SRE team only (kubectl) → any QA engineer, developer, or manager
• Knowledge required: YAML, CRD schema, kubectl, K8s auth → open browser, click buttons
• Time to trigger an experiment: ~1 min (with operator) → ~10 seconds (select, click, done)
• Time to understand cluster state: kubectl get + parse YAML output → glance at dashboard
• Experiment history: grep Prometheus or operator logs → searchable table + timeline + reports
• Organization-wide coverage view: custom Grafana dashboard → built-in Topology view
• Bulk testing for releases: script loops with kubectl → one-click Bulk Operations
• Recurring test configuration: edit YAML, re-apply CR → visual schedule builder

The QA UI transforms chaos engineering from an SRE-gated, terminal-only activity into a self-service capability available to the entire engineering organization.

10. Technology Stack

• Operator Runtime — Python 3.13 + Kopf 1.36 for CRD reconciliation, timer handlers, and leader election.
• Template Engine — Jinja2 3.1 for ChaosEngine YAML rendering.
• Schedule Engine — croniter 6.2 for cron expression parsing.
• CRD — chaos.platform.io/v1alpha1 ChaosExperiment custom resource.
• Experiment Engine — LitmusChaos 3.9 (go-runner, chaos-runner, ChaosResult).
• Policy Enforcement — Kyverno for forbidden namespaces and required labels.
• Observability — Prometheus + Grafana with 6 metrics, 10 alerts, and 2 dashboards.
• QA UI Frontend — React 18 + Tailwind CSS v4 (CDN) as a single-file SPA, no build step required.
• QA UI Backend — Python 3.13 + FastAPI 0.115 with a Kubernetes API client, SQLite history, and a REST API.
• QA UI Proxy — nginx for static file serving and reverse proxy to the backend.
• QA UI History — SQLite for experiment history, stats, and CSV/HTML reports.
• Container Registry — internal private registry for enterprise-grade artifact storage.
• CI/CD — Jenkins with SAST/SCA analysis, container vulnerability scanning, and image signing for build, scan, sign, and deploy.
• HA — 2 replicas + Kopf peering for leader election and automatic failover.

11. Key Takeaways

1. The value isn’t writing less YAML — it’s eliminating seven layers of operational complexity. Every layer we automated (discovery, RBAC, health checks, safety, scheduling, observability, lifecycle) is a layer that can no longer be forgotten, misconfigured, or skipped.
2. Guardrails enable adoption. Teams started using chaos testing when they knew it couldn’t accidentally hit kube-system or kill all replicas. Safety made trust possible.
3. Global defaults with local overrides is the right abstraction. One cron expression at the operator level gives every service recurring tests. Any team can override for their own needs. Zero coordination required.
4. Your first test will fail — and that’s the point. Our first pod-failure test killed 100% of pods and proved the service had zero graceful degradation. That finding alone justified the entire project.
5. A platform is not complete until non-experts can use it. The operator solved the complexity problem for SRE engineers. The QA UI solved the accessibility problem for everyone else. When a QA engineer can trigger, monitor, and report on chaos experiments from a browser without writing a single line of YAML or touching kubectl, chaos engineering stops being an SRE discipline and becomes an organizational capability.

Mert Polat is an Expert SRE at Intertech (DenizBank / Emirates NBD Group) and the LitmusChaos Turkey Community Lead. He initiated the chaos engineering effort within the organization, working in close collaboration with Architect SRE Buğra Çakmak, who designed the system architecture, and under the leadership of their manager Salih Eligüzel, who championed and enabled the initiative.

Together, they built a production-grade chaos engineering platform that proves services can survive failure — from Kubernetes operators that automate resilience testing to browser-based interfaces that make chaos engineering accessible to the entire organization.

Intertech is listed as an official LitmusChaos adopter at litmuschaos.io

Building a Production Chaos Engineering Platform: From Manual Operations to Automated Resilience… was originally published in Intertech on Medium, where people are continuing the conversation by highlighting and responding to this story.

1. Problem

Fintech’te Kesinti Lüksün Yok

Intertech, DenizBank/Emirates NBD grubunun teknoloji şirketi — Türkiye’nin en büyük fintech’i. Her gün milyonlarca finansal işlem. Bir dakika kesinti? Regülatör soruşturması, para kaybı, müşteri güveni gitti.

SRE olarak tek bir prensibimiz vardı: production’a çıkmak isteyen servis, önce bize dayanıklılığını kanıtlayacak. Kulağa hoş geliyor. Ama 1000+ mikroservis varken bunu nasıl sistematik yapacaksın? İşte asıl problem buydu.

Mevcut Araçlar Neden Yetmedi?

LitmusChaos’u erkenden aldık — sağlam bir chaos engine. Ama 1000+ servise ölçeklemeye çalışınca, tek bir aracın çözemeyeceği yedi farklı karmaşıklık katmanı çıktı karşımıza:

Katman 1 — Experiment Config Her test için 80+ satır ChaosEngine YAML yaz (appinfo, serviceAccount, probe, env var, label, annotation).

Katman 2 — Service Discovery applabel, owner, SRE team bilgisini bul, elle yaz.

Katman 3 — Health Check Doğru readiness probe endpoint’ini bul, URL’i oluştur.

Katman 4 — RBAC Her namespace için ServiceAccount + Role + RoleBinding oluştur.

Katman 5 — Güvenlik kube-system'de veya düşük replica senaryolarında chaos çalışmasını engelleyecek bir mekanizma yok.

Katman 6 — Observability Birleşik metrik yok, dashboard yok, chaos run’larıyla SLO etkisi arasında korelasyon yok.

Katman 7 — Scheduling Her test manuel tetikleniyor — otomasyon yok, tekrar yok, merkezi kontrol yok.

Sonuç mu? Chaos testi sadece SRE yapıyordu — o da ayda bir, şansımız yaver giderse. Her test 20–30 dakika YAML yazmak demekti. 1000+ serviste chaos engineering? Güzel bir fikirdi, hayata geçiremedik.

Gerçek Maliyet

Bu sadece developer experience problemi değildi. Dayanıklılık coverage’ı sıfıra yakındı:

• 1000+ servisten sadece ~5 tanesi chaos testi görmüştü
• Recurring test yapan servis sayısı: sıfır
• Chaos sonuçları ile production SLO’lar arasında korelasyon: sıfır
• kube-system gibi kritik namespace'leri koruyan guardrail: sıfır
• Her test one-off, sonuçlar Slack’te bir yerde kayboluyordu
• QA mühendisleri veya developer’lar katılamıyordu — SRE el tutmadan olmuyor

2. Çözüm: Yedi Katmanı Tek Operatörle Çözmek

Her katmanı ayrı ayrı çözmek yerine, tek bir Kubernetes operatörü yazdım. Yedi katmanın hepsini deklaratif bir CRD arkasında otomatikleştiriyor. Üstüne bir de browser-based QA arayüzü ekledik — artık kimse terminal açmadan chaos test yapabiliyor.

Temel Prensip

Kullanıcı ne istediğini söyler. Operatör gerisini halleder.

Bir developer şunu yazıyor:

apiVersion: chaos.platform.io/v1alpha1
kind: ChaosExperiment
metadata:
  name: gateway
  namespace: gateway
spec:
  experiments:
    - type: pod-failure
    - type: network-loss

Bu kadar. Service discovery yok. RBAC yok. Probe URL yok. Template yok. Operatör yedi katmanı otomatik çözüyor.

Arka Planda Ne Oluyor?

Developer Input (3 satır config)
         │
         ▼
┌─────────────────────────────────────────────────────┐
│         CHAOS PLATFORM CONTROLLER                    │
│                                                      │
│  Katman 1 ✓  Experiment Registry → akıllı default'lar│
│  Katman 2 ✓  Deployment label'ları → owner, SRE team │
│  Katman 3 ✓  ReadinessProbe → health check URL       │
│  Katman 4 ✓  Auto SA + Role + RoleBinding            │
│  Katman 5 ✓  Kill switch, min replica, forbidden NS  │
│  Katman 6 ✓  Prometheus metrics + Grafana            │
│  Katman 7 ✓  Cron scheduling + global default'lar    │
│                                                      │
│  Output: Tam configure edilmiş Litmus ChaosEngine    │
└──────────────────────┬──────────────────────────────┘
                       ▼
              LitmusChaos Engine
              → Runner Pod → Experiment → ChaosResult

Neden Operatör? Neden Script veya Helm Değil?

Helm charts — Olmadı. Yine 30+ satır values file. Runtime intelligence yok. Reconciliation yok.

Shell scripts — Olmadı. State tracking yok, retry yok, status reporting yok. Kırılgan.

LitmusChaos GameDay API — Olmadı. One-off run’lar için tamam, ama GitOps-friendly CR modeli yok, Kubernetes-native lifecycle yok.

Custom Kopf Operatörü ✅ — Seçildi. Kubernetes-native CRD. Reconciliation loop. Timer handler. Status management. Leader election. GitOps uyumlu.

3. Beklenen Kazanım

Build etmeden önce hesabı yaptık.

Servis Başına Süre Karşılaştırması

ChaosEngine YAML’ı elle yazmak ~15 dakika sürüyordu. Operatör otomatik üretiyor.

Service label ve owner bilgisini bulmak her experiment’ta ~5 dakika alıyordu. Operatör Deployment label’larından otomatik discover ediyor.

Doğru health check endpoint’ini bulmak ~5 dakika sürüyordu. Operatör readiness probe’dan otomatik detect ediyor.

RBAC resource’larını oluşturmak ~5 dakika sürüyordu. Operatör ServiceAccount, Role ve RoleBinding’i idempotent olarak auto-provision ediyor.

Güvenlik kontrolleri (namespace allowlist, minimum replica) manuel review’da ~3 dakika alıyordu. Operatör otomatik enforce ediyor.

Toplam: ~33 dakika → ~1 dakika (3 satır YAML yaz, apply et).

Ölçek Etkisi

• Experiment başına setup süresi: ~33 dk → ~1 dk — %97 azalma
• Chaos coverage olan servis: 5 → 1000+ potansiyel — 200× artış
• Recurring otomatik test: 0 → sınırsız (cron ile) — ∞
• Test başına manuel YAML satırı: 80+ → 3 — %96 azalma
• Namespace başına RBAC setup: manuel → otomatik — ortadan kalktı
• Olası güvenlik incident’ı: var → yok (kill switch + guardrail’ler) — ortadan kalktı

4. İmplementasyon

4.1 Mimari

┌─────────────────────────────────────────────────────────────────────────┐
│                     KUBERNETES CLUSTER (GKE/Anthos)                     │
│                                                                         │
│  ┌───────────────────────────────────────────────────────────────────┐  │
│  │        CHAOS PLATFORM CONTROLLER (Python 3.13 / Kopf 1.36)        │  │
│  │        2 replica — Leader Election — HA                           │  │
│  │                                                                   │  │
│  │  on.create/update  →  ChaosExperiment CR reconcile                │  │
│  │  timer(60s)        →  ChaosResult poll, status update             │  │
│  │  timer(60s)        →  Cron schedule check, experiment trigger     │  │
│  │  timer(120s)       →  Blocked experiment retry                    │  │
│  │  on.delete         →  Engine, runner, result cleanup              │  │
│  │  on.resume         →  Restart sonrası Running experiment devralma │  │
│  └───────────────────────────────────────────────────────────────────┘  │
│                          │                                              │
│           ┌──────────────┼───────────────┐                              │
│           ▼              ▼               ▼                              │
│  ┌──────────────┐ ┌───────────┐ ┌───────────────┐                       │
│  │ LitmusChaos  │ │Prometheus │ │    Kyverno    │                       │
│  │ ChaosEngine  │ │ 6 metrik  │ │   Policy'ler  │                       │
│  │ Runner Pod   │ │ 10 alert  │ │ Forbidden NS  │                       │
│  │ ChaosResult  │ │ 2 dashbrd │ │ Required Label│                       │
│  └──────────────┘ └───────────┘ └───────────────┘                       │
└─────────────────────────────────────────────────────────────────────────┘

4.2 Yedi Katman — Nasıl Çözüldü?

Katman 1: Experiment Registry — Akıllı Default’lar

Her experiment tipi bir Litmus experiment’a, bir Jinja2 template’e ve production’da test edilmiş default’lara map’leniyor:

EXPERIMENT_REGISTRY = {
    "pod-failure": {
        "litmus_name": "pod-delete",
        "template": "pod-failure/base.yaml",
        "defaults": {
            "duration": "60",
            "pods_affected_perc": "50",  # Asla %100 kill etme — acı tecrübe
            "force": "false",
        },
    },
    "network-loss": {
        "litmus_name": "pod-network-loss",
        "template": "network-loss/base.yaml",
        "defaults": {
            "duration": "60",
            "packet_loss_perc": "30",
            "network_interface": "eth0",
        },
    },
    # Toplam 6 experiment tipi: cpu-stress, memory-stress, pod-failure,
    # pod-kill, network-loss, network-failure
}

pods_affected_perc: "50" default'u acı bir dersin ürünü — ilk testimiz pod'ların %100'ünü öldürdü, servis tamamen gitti. Şimdi yarısı trafik serve ederken diğer yarısı test ediliyor.

Katman 2: Otomatik Service Discovery

Operatör Deployment label’larını okuyor — user input gerekmiyor:

def detect_service_info(namespace, cr_name):
    deployments = apps_api.list_namespaced_deployment(namespace)
    target = _find_target_deployment(deployments, cr_name)
    labels = target.metadata.labels or {}
    return {
        "owner": labels.get("owner", "unknown"),
        "sre_team": labels.get("sreTeamName", "unknown"),
        "app_label": _detect_app_label(target),
    }

CR adı Deployment adıyla eşleşiyor. Owner ve SRE team zaten her Intertech deployment’ında olan standart label’lardan geliyor.

Katman 3: Otomatik Health Check Detection

Operatör target Deployment’ın readinessProbe'unu okuyup health check URL'ini oluşturuyor:

python

def detect_health_check_url(namespace, service_name):
    for container in target_deploy.spec.template.spec.containers:
        probe = container.readiness_probe or container.liveness_probe
        if probe and probe.http_get:
            path = probe.http_get.path or "/health"
            port = probe.http_get.port or service_port
            return f"http://{service_name}.{namespace}.svc.cluster.local:{port}{path}"

Bu URL experiment süresince continuous HTTP probe olarak çalışıyor — health check fail ederse experiment verdict’i Fail oluyor.

Katman 4: Dynamic RBAC

Her target namespace için Litmus’un ihtiyacı olan ServiceAccount + Role + RoleBinding operatör tarafından idempotent olarak oluşturuluyor. Manuel setup sıfır.

Katman 5: Güvenlik Guardrail’leri (Defense in Depth)

Beş bağımsız güvenlik mekanizması — herhangi biri tek başına bir experiment’ı durdurabilir:

• Kill Switch — chaos-operator-kill-switch adında bir ConfigMap. enabled: "false" yapınca cluster genelindeki TÜM chaos anında duruyor.
• Forbidden Namespace’ler — kube-system, istio-system, chaosplatform ve diğerleri. Operatörde hardcoded, üstüne Kyverno policy ile defense in depth.
• Min Replica Check — Target Deployment’ın replica sayısı 2'den azsa destructive experiment’lar blocked.
• Concurrent Limit — Cluster genelinde aynı anda max 5 experiment çalışabilir.
• Phased Execution — Non-destructive testler (cpu-stress, network-loss) önce çalışır. Destructive testler (pod-failure, pod-kill) ancak Phase 1 bittikten sonra başlar.

Phased Execution özellikle önemli. Bir CR’da hem network-loss hem pod-failure varsa:

Phase 1 (Non-Destructive)          Phase 2 (Destructive)
┌─────────────────────┐            ┌─────────────────────┐
│  network-loss       │ ──bitti──▶ │  pod-failure        │
│  cpu-stress         │            │  pod-kill           │
└─────────────────────┘            └─────────────────────┘

Bu sayede pod-failure pod’ları öldürürken network-loss hâlâ ölçüm yapmaya çalışmıyor — misleading sonuçlar önleniyor.

Katman 6: Observability

Owner/SRE team label’lı altı Prometheus metric:

• chaos_experiment_result_total (Counter) — servis, tip ve team bazında pass/fail sonuçları.
• chaos_engine_status (Gauge) — şu an running engine sayısı.
• chaos_operator_errors_total (Counter) — operatör error'ları tipe göre.
• chaos_operator_reconcile_queue_length (Gauge) — reconcile backlog.
• chaos_experiment_start_time (Gauge) — experiment start timestamp'leri.
• chaos_policy_violation_total (Counter) — policy violation attempt'leri.

Üstüne 10 Prometheus alert rule — aralarında SLO breach correlation da var: chaos experiment aktifken error rate %5'i geçerse alert tetikleniyor.

Katman 7: Scheduling & Global Default’lar

En son eklediğimiz feature — iki kademeli cron scheduling:

Kademe 1 — Operatör Global Default:

# Deployment env variable — TÜM ChaosExperiment'lara uygulanıyor
env:
  - name: DEFAULT_SCHEDULE
    value: "0 14 * * 1-5"    # Hafta içi her gün 14:00 UTC
  - name: DEFAULT_SUSPEND
    value: "false"

Kademe 2 — CR Bazında Override:

spec:
  schedule: "0 10 * * 1,3"   # Bu CR: Pazartesi/Çarşamba 10:00 — global'ı eziyor

Öncelik: CR spec.schedule > Operatör DEFAULT_SCHEDULE > Yok (one-shot)

Yani: tek bir global cron ayarla, her CR otomatik recurring test haline gelsin. İsteyen CR kendi schedule’ıyla override edebilir.

4.3 Dry-Run Mode

Production’da gerçek chaos çalıştırmadan önce planı validate et:

spec:
  dryRun: true
  experiments:
    - type: pod-failure
    - type: network-loss

Operatör servisi discover ediyor, phased execution planını hesaplıyor, her şeyi status’a yazıyor — tek bir ChaosEngine oluşturmadan. İlk entegrasyon için ideal.

4.4 High Availability

Operatör 2 replica ve Kopf leader election ile çalışıyor. Sadece leader reconcile yapıyor — leader pod ölürse ikincisi otomatik devralıyor. Running experiment’lar Kopf’un resume handler’ı ile tekrar işleniyor.

5. Somut Sonuçlar

Canlı Test: gateway/gateway (Network Loss)

İlk production testimiz gateway namespace'indeki gateway servisini hedef aldı:

1. CR apply: dryRun=true   → phase: DryRun    ✓ Plan validate edildi
2. CR apply: dryRun=false  → phase: Running   ✓ ChaosEngine oluştu
3. Runner pod başladı      → experiment pod   ✓ Network loss inject edildi
4. Health probe            → continuous check ✓ Servis sağlıklı kaldı
5. ChaosResult             → verdict: Pass    ✓ %30 packet loss'a dayandı
6. CR status               → phase: Completed ✓ lastResult: Success

Servis %30 network packet loss’u sıfır health check failure ile geçti.

Global Schedule Test

spec.schedule olmadan bir CR apply ettik — operatör global DEFAULT_SCHEDULE'ı aldı:

1. CR apply (schedule field yok)  → Operatör DEFAULT_SCHEDULE="*/2 * * * *" kullandı
2. Status                         → phase: Scheduled, nextExecution: 2 dk sonra
3. 2 dakika sonra                 → "Schedule tetiklendi" — experiment otomatik çalıştı
4. Completion sonrası             → Sonraki window için yeniden schedule edildi

CR’da sıfır config — tamamen operatör-level default’larla otomatik.

Coverage Etkisi

• Chaos testi olan servis: 5 → 30+ (haftalık artıyor)
• Recurring scheduled test: 0 → hepsi (global cron ile)
• Ortalama setup süresi: ~33 dk → 1 dakikanın altında
• Test başına manuel YAML: 80+ satır → 3 satır
• Güvenlik incident’ı: mümkün → imkansız (5 katman guardrail)
• Prometheus’ta chaos sonuçları: yok → her run, team label’lı

6. Yeni Servis Ekleme — Developer Guide

Basit Case: Tüm Default’ları Kabul Et

Bir developer payments namespace'indeki payment-api servisi için chaos testi eklemek istiyor:

apiVersion: chaos.platform.io/v1alpha1
kind: ChaosExperiment
metadata:
  name: payment-api        # Deployment adıyla eşleşmeli
  namespace: payments      # Target namespace
spec:
  experiments:
    - type: pod-failure

Bu kadar. kubectl apply -f ile uygula:

• ✅ Operatör Deployment label’larından owner ve sreTeamName discover ediyor
• ✅ Health check URL readiness probe’dan otomatik detect ediliyor
• ✅ RBAC payments namespace'inde otomatik oluşturuluyor
• ✅ Litmus ChaosEngine production-tested default’larla render ediliyor
• ✅ Sonuçlar team label’lı Prometheus metric’lerine gidiyor
• ✅ Global DEFAULT_SCHEDULE ayarlıysa o schedule'da otomatik çalışıyor

Birden Fazla Experiment Tipi

spec:
  experiments:
    - type: pod-failure     # Destructive — Phase 2'de çalışır
    - type: network-loss    # Non-destructive — Phase 1'de çalışır
    - type: cpu-stress      # Non-destructive — Phase 1'de çalışır

Operatör otomatik phase’lere ayırıyor: network-loss + cpu-stress önce, sonra pod-failure.

Custom Schedule (Global’ı Override Et)

spec:
  schedule: "0 3 * * 6"    # Sadece Cumartesi 03:00 — global default'ı eziyor
  experiments:
    - type: pod-failure

Run Etmeden Validate Et (Dry-Run)

spec:
  dryRun: true
  experiments:
    - type: pod-failure
    - type: network-loss

Planı kontrol et: kubectl get chaosexperiment payment-api -n payments -o yaml → status'ta ne olacağı görünüyor.

Silmeden Pause Et

kubectl patch chaosexperiment payment-api -n payments \
  -p '{"spec":{"suspend":true}}' --type=merge

Resume:

kubectl patch chaosexperiment payment-api -n payments \
  -p '{"spec":{"suspend":false}}' --type=merge

Sonuçları İzle

# Tüm experiment'lar bir bakışta
kubectl get chaosexperiments -A
# Output:
# NS         NAME          SERVICE       PHASE      SCHEDULE         NEXT RUN
# gateway    gateway       gateway       Scheduled  0 14 * * 1-5     2026-03-31T14:00
# payments   payment-api   payment-api   Completed                   -

7. Desteklenen Experiment Tipleri

• pod-failure — graceful deletion sonrası pod recovery'yi test ediyor. Default impact: pod'ların %50'si, 60 saniye.
• pod-kill — force kill sonrası pod recovery'yi test ediyor. Default impact: pod'ların %50'si, 60 saniye.
• cpu-stress — CPU pressure altında davranışı test ediyor. Default impact: 1 core, %80 load, 60 saniye.
• memory-stress — memory pressure altında davranışı test ediyor. Default impact: 128MB allocation, 60 saniye.
• network-loss — packet loss'a dayanıklılığı test ediyor. Default impact: %30 loss, 60 saniye.
• network-failure — ağır packet loss'a dayanıklılığı test ediyor. Default impact: %50 loss, 60 saniye.

8. Operasyonel Komutlar

Tüm chaos’u durdur (acil):

kubectl -n chaosplatform patch cm chaos-operator-kill-switch \
  -p '{"data":{"enabled":"false"}}'

Acil durum sonrası devam:

kubectl -n chaosplatform patch cm chaos-operator-kill-switch \
  -p '{"data":{"enabled":"true"}}'

Global schedule ayarla:

kubectl -n chaosplatform set env deployment/chaos-operator \
  DEFAULT_SCHEDULE="0 14 * * 1-5"

Tüm schedule’ları duraklat:

kubectl -n chaosplatform set env deployment/chaos-operator \
  DEFAULT_SUSPEND="true"

Tek experiment’ı pause et:

kubectl patch chaosexperiment <name> -n <ns> \
  -p '{"spec":{"suspend":true}}' --type=merge

Operatör loglarını gör:

kubectl -n chaosplatform logs deployment/chaos-operator --tail=50

9. QA Test Arayüzü — Chaos Engineering’i Herkese Açmak

Son Engel

Operatör experiment setup’ını 33 dakikadan 1 dakikaya indirdi — ama o 1 dakika hâlâ şunları gerektiriyordu:

1. Kubernetes cluster’a SSH veya VPN erişimi
2. kubectl kurulu ve configure edilmiş
3. YAML syntax ve CRD schema bilgisi
4. Status kontrol, log okuma, debug için terminal literacy

SRE için sorun değil. Ama QA mühendisleri, developer’lar ve product team’ler için? Release öncesi dayanıklılık validate etmek istiyorlar ama araç setleri buna uygun değil. Sıfır kubectl, browser-based bir arayüz lazımdı — cluster içinde çalışan, doğrudan Kubernetes API ile konuşan.

Mimari: In-Cluster Real-Time Dashboard

QA UI, operatörle aynı chaosplatform namespace'inde first-class Kubernetes workload olarak çalışıyor. Statik bir dashboard değil — ChaosExperiment custom resource'ları için live, read-write control plane.

┌──────────────────────────────────────────────────────────────────────────────┐
│                     KUBERNETES CLUSTER                                       │
│                                                                              │
│  ┌──────────────────────────────────────────┐  ┌──────────────────────────┐  │
│  │   CHAOS PLATFORM CONTROLLER (Kopf)       │  │    QA UI Pod             │  │
│  │   ChaosExperiment CR'ları reconcile eder │  │  ┌─────────┐ ┌────────┐  │  │
│  │   ChaosEngine oluşturur                  │◀─│  │ nginx   │ │FastAPI │  │  │
│  │   ChaosResult'ları izler                 │  │  │ :80     │ │ :8000  │  │  │
│  │   CR status günceller                    │  │  │ React   │ │ K8s API│  │  │
│  └──────────────────────────────────────────┘  │  │ SPA     │ │ Client │  │  │
│              ▲         ▲                       │  └────┬────┘ └───┬────┘  │  │
│              │         │                       │       │          │       │  │
│     ChaosEngine   ChaosResult                  │       │   REST   │       │  │
│              │         │                       │       └────┬─────┘       │  │
│              │         │                       │            │             │  │
│  ┌───────────┴─────────┴──────┐                │            ▼             │  │
│  │      LitmusChaos           │                │   ServiceAccount RBAC    │  │
│  │      Runner Pods           │                │   (read deployments,     │  │
│  │      Chaos Experiments     │                │    CRUD experiments,     │  │
│  └────────────────────────────┘                │    read kill switch)     │  │
│                                                └──────────────────────────┘  │
│                                                                              │
│  ┌──────────────────────────────────────────────────────────────────────────┐│
│  │ Ingress: chaos-qa.preprod.internal → QA UI Service :80                  ││
│  └──────────────────────────────────────────────────────────────────────────┘│
└──────────────────────────────────────────────────────────────────────────────┘

Kritik mimari kararlar:

• In-cluster deployment: FastAPI backend load_incluster_config() kullanıyor — kubeconfig file yok, credential saklanmıyor. Kubernetes API'ye pod'un ServiceAccount token'ı ile erişiliyor, otomatik mount ve rotate ediliyor.
• RBAC-scoped access: Dedicated ClusterRole UI'ın tam ihtiyacını veriyor — chaosexperiments üzerinde CRUD, deployment ve namespace'lerde read-only, kill switch ConfigMap'inde read. Fazlası yok.
• İki container pod: nginx React SPA’yı port 80'de serve ediyor, /api/* isteklerini port 8000'deki FastAPI backend'e reverse proxy yapıyor. Production'da CORS sorunu yok. Tek pod, tek service, tek ingress.
• SQLite history: Experiment history PVC-backed SQLite database’inde persist ediliyor — pod restart’larında dayanıklı, external database dependency yok.

UI Ne Yapabiliyor? — Browser’dan Full Lifecycle

Daha önce kubectl komutu olan her operasyon artık bir button click:

• Allowed namespace’leri listele — kubectl get ns yerine allowed list'e göre filtrelenmiş namespace dropdown.
• Deployment’ları listele — kubectl get deploy -n gateway yerine live replica status'lu deployment dropdown.
• Experiment oluştur — kubectl apply -f experiment.yaml yerine "tipleri seç → Run Experiment tıkla".
• Experiment sil — kubectl delete chaosexperiment gateway -n gateway yerine experiment card'ında Delete butonu.
• Experiment status gör — kubectl get chaosexperiment -o yaml yerine phase badge'li real-time dashboard.
• Schedule’ı suspend et — kubectl patch ... suspend=true yerine Suspend butonu.
• Acil durdur — kill-switch patch komutu yerine header’da kill switch indicator.
• Experiment history gör — Prometheus veya log grep yerine filtreli, CSV export’lu searchable history table.

Real-Time Kubernetes Interaction

UI statik bir sayfa değil, demand üzerine refresh etmiyor. Cluster state’inin continuous real-time awareness’ını koruyor:

1. 10 saniyelik auto-refresh: Frontend tüm aktif experiment’ları, stat’ları ve kill switch status’unu her 10 saniyede bir poll ediyor. Refresh cycle devam ederken spinning indicator görünüyor.
2. Live countdown timer’lar: Experiment Running phase'indeyken dashboard her saniye tick eden live elapsed-time counter gösteriyor — cluster'da bir şeyler olduğunun anında görsel feedback'i.
3. Phase transition tracking: Operatör ChaosExperiment’ı lifecycle boyunca reconcile ederken (Pending → Running → Completed), UI her transition'ı real-time color-coded phase badge'leriyle yansıtıyor.
4. Instant deployment discovery: QA engineer namespace seçtiğinde backend Kubernetes API’yi real-time sorguluyor ve deployment’ları current replica count’larıyla listeliyor. Cache değil — cluster’ın live state’i. Yeni scale edilmiş deployment anında görünüyor.

Experiment Oluşturma — Sıfır YAML, Full Güç

QA engineer UI üzerinden experiment oluştururken şunu görüyor:

Step 1 — Target Seç:

• Filtered dropdown’dan namespace seç (sadece allowed namespace’ler görünüyor)
• Live-queried listeden deployment seç (ready/total replica count görünüyor)
• Sık kullanılan deployment’ları one-click erişim için pin’le

Step 2 — Experiment Tiplerini Seç:

• Altı experiment type card’ı, açıklamaları ve destructive/non-destructive badge’leri
• Multiple selection — operatör phased execution’ı otomatik hallediyor
• Phase indicator’lar hangi experiment’ların Phase 1 vs Phase 2'de çalışacağını gösteriyor

Step 3 — Option’ları Configure Et:

• Dry Run toggle: Tek bir ChaosEngine oluşturmadan execution planını validate et
• Schedule builder: Preset’li (weekdays, daily, weekly) veya custom cron input’lu görsel cron builder — human-readable preview gösteriyor (“Every weekday at 14:00 UTC”)
• Tag’ler: Experiment’ları kategorize et (sprint-42, team-sre, regression)

Step 4 — Execution Planını Review Et: Live sidebar tam olarak ne olacağını gösteriyor:

• Target deployment
• Phase 1 experiment’ları (non-destructive)
• Phase 2 experiment’ları (destructive)
• Uygulanacak safety guardrail’ler
• Mode badge’leri (DRY RUN, SCHEDULED, DESTRUCTIVE)

Step 5 — Confirm ve Run:

• Non-destructive experiment’lar click’le anında çalışıyor
• Destructive experiment’lar kırmızı uyarılı confirmation modal tetikliyor
• Backend /api/experiments'a POST yapıyor, o da Kubernetes API'yi çağırıp ChaosExperiment CR oluşturuyor
• Operatör saniyeler içinde alıp reconciliation başlatıyor
• UI otomatik Dashboard’a yönlendiriyor, experiment real-time görünüyor

Confirmation Safety Net

QA engineer dry-run mode olmadan destructive experiment tipleri (pod-failure, pod-kill) seçtiğinde, UI zorunlu confirmation modal gösteriyor:

⚠️ Destructive Experiment

gateway/gateway üzerinde destructive chaos experiment'ları
çalıştırmak üzeresiniz. Bu live pod'ları etkileyecek.
┌─────────────────────────────────┐
│ 💥 Pod Failure                  │
│ ☠️ Pod Kill                     │
└─────────────────────────────────┘
[Cancel]        [Confirm & Run]

Bu bilinçli bir UX kararı — UI güvenli şeyleri kolay, tehlikeli şeyleri bilinçli yapmalı. Operatörün beş katmanlı guardrail’leriyle birlikte, istenmeyen hasar vermek aşırı zorlaşıyor.

Dashboard — Live Cluster State

Dashboard view tüm allowed namespace’lerdeki tüm experiment’ların real-time overview’ını sağlıyor:

• Stats bar: Active / Passed / Failed / Scheduled / Total — Kubernetes’ten her 10 saniyede güncelleniyor
• Experiment card’lar: Her card experiment adı, namespace, phase badge (Running için color-coded ve animated), experiment tipleri, creation time ve schedule gösteriyor
• Phase filter’lar: All / Active / Completed / Scheduled view’ları arasında toggle
• Global search: Tüm cluster’da ad, namespace veya experiment tipine göre experiment filtrele
• Live countdown: Running experiment’lar pulsing animation’lı elapsed time gösteriyor
• Detail modal: Herhangi bir experiment card’a tıkla, operatörün CR status’una kaydettiği her phase transition dahil full status history gör

History & Reporting

UI üzerinden tetiklenen her experiment SQLite database’inde full metadata ile kaydediliyor — namespace ve deployment user selection’dan, experiment tipleri user selection’dan, phase ve result Kubernetes API’den poll ediliyor, cron schedule expression’ı, start timestamp ve duration, ve trigger source (UI-initiated experiment’lar için her zaman “qa-ui”).

Bu data şunları destekliyor:

• 14 günlük timeline chart: Günlük experiment aktivitesi, success/failure breakdown’lı bar chart
• Success rate widget: Overall pass rate’i namespace breakdown’lı gösteren SVG ring chart
• HTML report generator: Stat’lar, chart’lar ve full experiment table’lı tek tıkla indirilebilir rapor
• CSV export: Excel veya BI tool’larında analiz için raw data export

Topology View — Cluster-Wide Visibility

Topology view tüm allowed namespace’leri interactive card’lar halinde grid olarak gösteriyor:

• Her card namespace adı, deployment count ve active/completed/failed experiment count’ları gösteriyor
• Color-coded status indicator’lar: yeşil (healthy), amber pulsing animation’lı (experiment’lar çalışıyor), kırmızı (failure’lar)
• Herhangi bir namespace’e tıkla, o namespace’deki tüm experiment’ları phase badge’leriyle gör

Bu, leadership ve SRE manager’lara tüm organizasyondaki chaos engineering coverage’ının tek ekranlık görünümünü veriyor.

Template’ler & Quick Action’lar — Tekrarlayan İşleri Hızlandırma

QA team’leri genelde aynı experiment’ları tekrar tekrar çalıştırıyor — UI bunu frictionless yapıyor:

• Save as Template: Experiment configure ettikten sonra “Save Template” tıkla, full configuration’ı (namespace, deployment, tipler, schedule, tag’ler) localStorage’a kaydet
• Template Gallery: Kaydedilmiş template’leri browse et, rename et, sil veya trigger form’una anında yükle
• Quick Re-run: Son 6 experiment trigger sayfasında one-click card olarak görünüyor
• Pinned Deployment’lar: Sık test edilen deployment’ları session’lar arası instant access için yıldızla

Bulk Operation’lar — Enterprise Scale

Organization-wide resilience campaign’leri için (örn. pre-release regression), Bulk Operations modal şunları sağlıyor:

1. Birden fazla namespace’i aynı anda seç
2. Experiment tiplerini seç
3. Dry-run mode seç (bulk için önerilen)
4. Tek click tüm seçili namespace’lerde experiment oluşturuyor

UI raporluyor: “Bulk: 12 experiment oluşturuldu, 0 failed” — her experiment sonra normal operatör reconciliation lifecycle’ını takip ediyor.

Dark/Light Tema & Accessibility

UI iki tema ile geliyor, localStorage’da persist ediliyor:

• Enterprise White (default): Temiz #F8F9FB background, #1E3A5F brand navy, kurumsal ortamlar ve projector sunumları için tasarlandı
• Dark Mode: #0F1117 background, #60A5FA accent blue, uzun monitoring session'ları ve SRE war room'ları için optimize edildi

Header’daki 🌙/☀️ button veya T keyboard shortcut ile toggle et.

Keyboard Shortcut’lar — Power User Workflow

Keyboard-driven workflow’u tercih eden SRE engineer’lar için:

• 1 – 5 — tab değiştir (Trigger → Dashboard → History → Templates → Topology)
• / veya Ctrl+K — search bar'a focus
• R — Kubernetes'ten tüm data'yı refresh et
• N — New Experiment'a git (Trigger tab)
• B — Bulk Operations'ı aç
• T — tema toggle et
• ? — shortcut yardımını göster
• Escape — modal'ları kapat / search'ü temizle

Focus input field’dayken tüm shortcut’lar disabled.

Mobile Responsive Design

UI hareket halinde monitoring için mobile ekranlara adapte oluyor:

• Header navigation horizontal scroll oluyor
• Stats bar 5 sütundan 2 sütuna (tablet) 1 sütuna (telefon) stack’leniyor
• Experiment card’lar dikey stack’leniyor
• Modal’lar full width’e uzuyor
• Touch-friendly button size’ları

Deployment Model

QA UI Kubernetes-native workload olarak deploy ediliyor:

# Tek Pod — 2 container
containers:
  - name: frontend     # nginx → React SPA :80'de
    image: <internal-registry>/chaosplatform/qa-ui-frontend:latest
  - name: backend      # FastAPI → K8s API client :8000'de
    image: <internal-registry>/chaosplatform/qa-ui-backend:latest
    env:
      - name: K8S_IN_CLUSTER
        value: "true"
      - name: ALLOWED_NAMESPACES
        value: "gateway,payments,fraud,identity,lending,notifications,insurance"

# RBAC
ClusterRole: chaosexperiments CRUD, deployments read, configmaps read
ServiceAccount: chaos-qa-ui-sa (namespace: chaosplatform)

# Storage
PVC: SQLite experiment history için 1Gi

# Access
Ingress: chaos-qa.preprod.internal

Tüm container image’ları internal private registry’den build ediliyor ve standart güvenlik pipeline’ından geçiyor — SAST/SCA analizi, container vulnerability scan ve image signing — deployment öncesi.

Etki: kubectl’den Self-Service’e

• Chaos experiment çalıştırabilen: sadece SRE (kubectl) → herhangi bir QA engineer, developer veya manager
• Gereken bilgi: YAML, CRD schema, kubectl, K8s auth → browser aç, button’lara tıkla
• Experiment tetikleme süresi: ~1 dk (operatörle) → ~10 sn (seç, tıkla, bitti)
• Cluster state’i anlama süresi: kubectl get + YAML output parse → dashboard'a bak
• Experiment history: Prometheus veya operatör loglarını grep’le → searchable table + timeline + report’lar
• Organization-wide coverage view: custom Grafana dashboard → built-in Topology view
• Release’ler için bulk test: kubectl ile script loop’ları → tek click Bulk Operations
• Recurring test configuration: YAML düzenle, CR’ı tekrar apply et → visual schedule builder

QA UI, chaos engineering’i SRE-gated, terminal-only aktiviteden tüm engineering organizasyonuna açık self-service capability’ye dönüştürüyor.

10. Teknoloji Stack’i

• Operator Runtime — Python 3.13 + Kopf 1.36, CRD reconciliation, timer handler ve leader election için.
• Template Engine — Jinja2 3.1, ChaosEngine YAML rendering için.
• Schedule Engine — croniter 6.2, cron expression parsing için.
• CRD — chaos.platform.io/v1alpha1 ChaosExperiment custom resource.
• Experiment Engine — LitmusChaos 3.9 (go-runner, chaos-runner, ChaosResult).
• Policy Enforcement — Kyverno, forbidden namespace ve required label için.
• Observability — Prometheus + Grafana, 6 metrik, 10 alert ve 2 dashboard.
• QA UI Frontend — React 18 + Tailwind CSS v4 (CDN), single-file SPA, build step gerektirmiyor.
• QA UI Backend — Python 3.13 + FastAPI 0.115, Kubernetes API client, SQLite history ve REST API.
• QA UI Proxy — nginx, static file serving ve backend’e reverse proxy.
• QA UI History — SQLite, experiment history, stat’lar ve CSV/HTML report’lar.
• Container Registry — internal private registry, enterprise-grade artifact storage.
• CI/CD — Jenkins + SAST/SCA analizi + container vulnerability scanning + image signing, build/scan/sign/deploy pipeline için.
• HA — 2 replica + Kopf peering, leader election ve automatic failover.

11. Önemli Çıkarımlar

1. Değer daha az YAML yazmak değil — yedi katman operasyonel karmaşıklığı ortadan kaldırmak. Otomatikleştirdiğimiz her katman (discovery, RBAC, health check, güvenlik, scheduling, observability, lifecycle) artık unutulamaz, yanlış configure edilemez veya atlanamaz.
2. Guardrail’ler adoption’ı mümkün kılıyor. Team’ler chaos testing’in yanlışlıkla kube-system'i vuramayacağını veya tüm replica'ları öldüremeyeceğini bildiklerinde kullanmaya başladı. Güvenlik güveni mümkün kıldı.
3. Global default + local override doğru abstraction. Operatör seviyesinde tek bir cron expression her servise recurring test veriyor. İsteyen team kendi ihtiyacına göre override edebilir. Sıfır koordinasyon gerekiyor.
4. İlk testin fail edecek — ve amaç da bu. İlk pod-failure testimiz pod’ların %100'ünü öldürdü ve servisin sıfır graceful degradation’ı olduğunu kanıtladı. Tek başına bu bulgu tüm projeyi haklı çıkardı.
5. Platform, uzman olmayanlar kullanana kadar tamamlanmış sayılmaz. Operatör SRE engineer’lar için karmaşıklık problemini çözdü. QA UI herkes için erişilebilirlik problemini çözdü. Bir QA engineer tek satır YAML yazmadan veya kubectl’e dokunmadan browser’dan chaos experiment tetikleyebildiğinde, izleyebildiğinde ve raporlayabildiğinde — chaos engineering SRE disiplini olmaktan çıkıp organizasyonel capability’ye dönüşüyor.

Mert Polat, Intertech (DenizBank / Emirates NBD Group) bünyesinde Expert SRE ve LitmusChaos Türkiye Topluluk Lideri olarak görev yapmaktadır. Kurum içinde chaos engineering girişimini başlatmış; sistem mimarisini tasarlayan Architect SRE Buğra Çakmak ile yakın iş birliği içinde çalışmış ve bu sürecin hayata geçirilmesini destekleyen yöneticileri Salih Eligüzel’in liderliğinde bu inisiyatifi ileri taşımıştır.

Birlikte, servislerin hatalara karşı dayanıklılığını kanıtlayan production-grade bir chaos engineering platformu geliştirmişlerdir — dayanıklılık testlerini otomatikleştiren Kubernetes operatörlerinden, chaos engineering’i organizasyon genelinde herkes için erişilebilir hale getiren tarayıcı tabanlı arayüzlere kadar uzanan bir yapı inşa edilmiştir.

Intertech, litmuschaos.io üzerinde resmi bir LitmusChaos kullanıcısı (adopter) olarak listelenmektedir.

Production’da Chaos Engineering Platformu: Manuel İşlerden Oto. Dayanıklılık Testine was originally published in Intertech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Real-Time Search Architecture with RediSearch and .NET Integration

Modern yazılım mimarilerinde performans, kullanıcı deneyimini doğrudan etkiler. Hepimiz o milisaniyeler içinde tepki veren autocomplete kutularına alıştık; açıkçası kullanıcıların beklemeye pek tahammülü yok. RDBMS tarafında veri bütünlüğü (integrity) konusunda içimiz rahat olsa da, iş metin tabanlı aramalara geldiğinde, özellikle o meşhur LIKE %...% sorgularının yarattığı performans maliyeti can sıkıcı olabiliyor.

Bu darboğazı aşmak için yıllardır başvurulan ilk çözüm genelde Elasticsearch oldu. Ancak in-memory teknolojilerin olgunlaşmasıyla birlikte RediSearch, özellikle real-time senaryolarda masadaki dengeyi değiştirecek güçlü bir oyuncu haline geldi.

RediSearch Nedir?

RediSearch, özünde Redis’in o bildiğimiz yüksek performanslı yapısının üzerine C ile yazılmış bir modül olarak geliyor. Redis denince aklımıza ilk gelen standart Key-Value eşleşmesinin sınırlarını aşıp, veriyi Ters Dizin (Inverted Index) yapısıyla tutmamıza olanak sağlıyor.

Peki kaputun altında ne dönüyor? Normalde Redis’te veriye ulaşmak için elinizde mutlaka bir key olması gerekir. RediSearch ise oyunun kurallarını değiştirip verinin içeriğini indeksliyor. Örneğin bir ürün açıklamasını alıyor, parçalıyor (tokenization), kelime köklerine iniyor (stemming) ve hangi kelimenin nerede geçtiğini tamamen RAM üzerinde haritalıyor. Tüm operasyon bellekte döndüğü için de milyonlarca kayıt arasında arama yapmak milisaniye değil, mikrosaniye mertebesinde gerçekleşebiliyor.

Temel Yetenekleri:

• Full-Text Search: Eş anlamlılar, stop-words, çok dilli kök bulma.
• Numeric & Geo Filtering: Konum tabanlı veya fiyat aralığına göre ultra hızlı filtrelemeler.
• Aggregation: Group by, sort, apply fonksiyonları (SQL benzeri).
• Auto-Complete: Fuzzy (bulanık) arama desteği ile hatalı yazımları tolere eden tamamlama önerileri.

Stop-words, arama sonuçlarını anlamlı şekilde etkilemeyen ve performans için göz ardı edilen sık kullanılan kelimelerdir.

Türkçe: ve, ile, için, da, de, bu, şu

İngilizce: the, is, at, of, and

Fuzzy search, yazım hatalarına rağmen benzer kelimeleri eşleştirerek arama deneyimini kesintisiz hâle getirir. Kelimeler arasındaki edit distance (Levenshtein mesafesi) gibi ölçütler kullanılarak benzerlik hesaplanır. Genellikle harf hatalarını, eksik karakterleri, küçük yazım farklarını tolere eder.

Kullanıcı: redi

Sistem: redis

Elasticsearch vs RediSearch

Projelerin tasarım aşamasında en sık karşılaştığımız yol ayrımlarından biri: “Hangi teknolojiyi seçmeliyiz?” Sektördeki birçok e-ticaret devinin Elasticsearch kullanıyor olması tesadüf değil; orada yılların getirdiği bir ekosistem ve güven var. Ancak yazılım dünyasında “Silver Bullet” (her sorunu çözen tek araç) diye bir şey yok; ihtiyaçlara göre doğru teraziyi kurmak, yani Trade-off (ödünleşim) analizi yapmak zorundayız.

[Silver Bullet]: Yazılım dünyasında her problemi tek başına ve kusursuzca çözdüğü varsayılan araç veya teknoloji anlamında kullanılan bir ifadedir.

[Trade-off]: Bir kazanım elde ederken başka bir avantajdan bilinçli olarak vazgeçme durumudur.

ÖZELLİK           ELASTICSEARCH (ES)                     REDISEARCH
------------------------------------------------------------------------------------------
Temel Teknoloji   Apache Lucene (Java)                   Redis Module (C)
------------------------------------------------------------------------------------------
Veri Saklama      Disk Ağırlıklı (RAM önbellek)          Bellek (RAM) Ağırlıklı
------------------------------------------------------------------------------------------
Performans        Hızlı (Milisaniyeler)                  Ultra Hızlı (ES'den %50'e varan hızlı)
------------------------------------------------------------------------------------------
Maliyet           Disk ucuzdur, ekonomiktir              RAM pahalıdır, maliyet artar
------------------------------------------------------------------------------------------
Sorgu Dili        Çok zengin JSON tabanlı DSL            Basit, SQL benzeri sözdizimi
------------------------------------------------------------------------------------------
Karmaşıklık       Yüksek (JVM, Sharding vb.)             Düşük (Redis yönetimi ile aynı)

Neden Hâlâ Elasticsearch?

RediSearch hızlı olsa da, aşağıdaki durumlarda Elasticsearch (veya OpenSearch) mimari açıdan daha doğru tercihtir:

1. Maliyet ve Veri Boyutu: 50 Milyon ürünlük bir kataloğu ve yıllara yayılan logları RAM’de (RediSearch) tutmak, bulut maliyetlerini (AWS/Azure) çok ciddi artırır. ElasticSearch bu veriyi ucuz disklerde tutar.
2. Derin Analitik ve Raporlama: “Son 6 ayda X kategorisine bakan ama Y ürününü almayan kullanıcıların yaş dağılımı” gibi karmaşık iş zekası sorgularında ElasticSearch çok daha yeteneklidir.
3. Ekosistem (ELK Stack): ElasticSearch sadece arama motoru değil, Kibana ile entegre devasa bir log yönetim platformudur.

Ne Zaman RediSearch?

• Instant Search (Anlık Arama): Kullanıcı harf bastığı anda tepki vermesi gereken Autocomplete modülleri.
• Önbellek Katmanı: Ana veri tabanının önünde duran, “Hot Data” (çok sık erişilen) arama motoru olarak.
• Ephemeral Data: Oturum bazlı veya geçici arama verileri.

Eğer sisteminizde halihazırda Redis kullanıyorsanız (Cache, Session vb. yönetimi için) ve sadece basit bir “Autocomplete” veya “Ürün Arama” özelliğine ihtiyacınız varsa; gidip sıfırdan bir Elasticsearch cluster’ı kurmak, yönetmek ve bakımını yapmak Overengineering (Aşırı Mühendislik) olabilir. Mevcut Redis’inizi RediSearch modülüyle güçlendirip, ekstra operasyonel maliyet yaratmadan bu işi çözmek çoğu zaman en akılcı yol olabilir.

Docker ile RediSearch

RediSearch’ü kullanmak için standart Redis imajı yeterli değildir. İçinde modüllerin yüklü olduğu redis-stack-server imajını kullanmalıyız.

redis/redis-stack-server - Docker Image

Aşağıdaki docker-compose.yml dosyası, hem arama motorunu hem de verileri görselleştirebileceğiniz RedisInsight arayüzünü ayağa kaldırır.

version: '3.8'
services:
  redis-stack:
    image: redis/redis-stack:latest
    container_name: redis-search-engine
    ports:
      - "6379:6379"  # Uygulama bağlantı portu
      - "8001:8001"  # RedisInsight UI (Görselleştirme)
    environment:
      - REDIS_ARGS="--requirepass 123456" # Prod için şifre
    volumes:
      - ./redis-data:/data
    deploy:
      resources:
        limits:
          memory: 2G # Bellek yönetimi kritiktir

Çalıştırmak için:

docker-compose up -d

Tarayıcınızdan http://localhost:8001 adresine giderek veri tabanınızı izleyebilir veya Redis Insight uygulamasını kurabilirsiniz.

Redis OM

Geçmişte RediSearch ile çalışırken FT.SEARCH index "@name:..." gibi string komutlar (magic strings) kullanılırdı. Bu yöntem hataya açıktır ve bakımı zordur.

Modern .NET mimarisinde, Redis OM .NET kütüphanesini kullanarak Entity Framework benzeri, tip güvenli (type-safe) ve LINQ destekli bir yapı kuracağız.

Gerekli paketi yükleyin:

dotnet add package Redis.OM

Redis.OM 1.1.0

Veri tabanı tablosu tanımlar gibi, Redis içinde saklayacağımız nesneyi ve indeksleme stratejisini Attribute'lar ile belirtebilirsiniz.

/// <summary>
/// RedisSearch üzerinde Türkçe içerik için optimize edilmiş ürün dokümanını temsil eder.
/// Türkçe kök bulma, stop-word filtreleme ve performanslı indeksleme ayarlarını içerir.
/// </summary>
[Document(
    /// <summary>
    /// Verilerin Redis tarafında Hash yapısı ile saklanacağını belirtir.
    /// Hash, RedisSearch için en performanslı depolama tipidir.
    /// </summary>
    StorageType = StorageType.Hash,

    /// <summary>
    /// Redis key’leri için kullanılacak prefix bilgisini tanımlar.
    /// Index tarama alanını daraltarak performansı artırır.
    /// </summary>
    Prefixes = new[] { "Product" },

    /// <summary>
    /// RedisSearch index adını belirtir.
    /// Varsayılan adlandırma yerine okunabilir ve yönetilebilir bir isim sağlar.
    /// </summary>
    IndexName = "search:idx:products:tr",

    /// <summary>
    /// Full-Text arama sırasında kullanılacak dili belirtir.
    /// Türkçe kök bulma ve metin analizi davranışlarını aktif eder.
    /// </summary>
    Language = "turkish",

    /// <summary>
    /// Indexleme sırasında göz ardı edilecek Türkçe stop-word listesini tanımlar.
    /// Anlamsız kelimeleri eleyerek arama kalitesini ve performansı artırır.
    /// </summary>
    Stopwords = new[]
    {
        "ve", "ile", "için", "bu", "şu", "bir",
        "da", "de", "mi", "mı", "mu", "mü"
    }
)]
public class Product
{
    /// <summary>
    /// Redis üzerinde dokümanın benzersiz kimliğini temsil eder.
    /// Varsayılan olarak ULID tabanlı otomatik ID üretimi kullanılır.
    /// </summary>
    [RedisIdField]
    public string Id { get; set; }

    /// <summary>
    /// Ürün adını temsil eder.
    /// Full-Text arama, sıralama ve metin analizi için indekslenir.
    /// </summary>
    [Searchable(Sortable = true)] //Alanı full-text arama için indeksler ve sonuçların bu alan üzerinden sıralanmasını sağlar.
    public string Name { get; set; }

    /// <summary>
    /// Ürün açıklamasını temsil eder.
    /// Full-Text arama için metin analizi uygulanır.
    /// </summary>
    [Searchable] //Alanı full-text arama için indeksler, metin analizi yapar ancak sıralamaya izin vermez.
    public string Description { get; set; }

    /// <summary>
    /// Ürünün ait olduğu kategori bilgisini temsil eder.
    /// Exact match ve filtreleme senaryoları için indekslenir.
    /// </summary>
    [Indexed]
    public string Category { get; set; }

    /// <summary>
    /// Ürünün satış fiyatını temsil eder.
    /// Sayısal filtreleme ve sıralama işlemleri için indekslenir.
    /// </summary>
    [Indexed(Sortable = true)] //Full-text arama yapmadan filtreleme ve aralık sorgularını hızlı çalıştırmak ve sonuçları bu alana göre sıralamak için kullanılır.
    public double Price { get; set; }
}
}

RedisOM for .NET

Aşağıdaki servis, indeks oluşturmayı (migration), veri eklemeyi ve tip güvenli aramayı yönetir. Ayrıca “Autocomplete” için hibrit bir yaklaşım içerir.

public sealed class ProductSearchService(
    IAutocompleteService autocompleteService,
    IRedisConnection redisConnection,
    IRedisCollection<Product> productRedisCollection) : IProductSearchService
{
    /// <inheritdoc />
    public async Task InitializeIndexAsync()
    {
        // Index zaten varsa tekrar oluşturmaya çalışması Redis OM tarafından yönetilir
        await redisConnection.CreateIndexAsync(typeof(Product));
    }

    /// <inheritdoc />
    public async Task IndexRangeAsync(IEnumerable<Product> products)
    {
        if (!products.Any()) return;

        // 1. Redis OM Collection'a TOPLU Ekleme (Bulk Insert)
        await productRedisCollection.InsertAsync(products);

        // 2. Autocomplete İndeksine Ekleme (Paralel)
        // Autocomplete servisi tekil çalıştığı için bunları paralel task olarak ateşliyoruz.
        var autocompleteTasks = products
            .Select(autocompleteService.IndexAsync);

        await Task.WhenAll(autocompleteTasks);
    }
}

public sealed class AutocompleteService(
    IRedisConnection connection, 
    IConnectionMultiplexer connectionMultiplexer) : IAutocompleteService
{
    private const string AutocompleteDictionaryKey = "autocomplete:products:dict:tr";

    public async Task IndexAsync(Product product)
    {
        string payload = JsonSerializer.Serialize(product);

        // 1. StackExchange.Redis'in "IBatch" özelliğini kullanıyoruz.
        // Bu, komutları bellekte biriktirir, ağa göndermez.
        var batch = connectionMultiplexer.GetDatabase().CreateBatch();

        // Geri dönüş değerlerini beklemek için task listesi
        List<Task> tasks = [];

        foreach (var (term, score) in product.Name.ToAutocompleteTerms())
        {
            // Batch üzerine ekliyoruz (Henüz Redis'e gitmedi)
            // FireAndForget: Cevabı bekleme, sadece gönder (Hız için kritik)
            Task task = batch.ExecuteAsync(
                "FT.SUGADD",
                AutocompleteDictionaryKey,
                term,
                score,
                "PAYLOAD",
                payload
            );

            tasks.Add(task);
        }

        // 2. Tüm komutları TEK BİR ağ paketinde sunucuya fırlat
        batch.Execute();

        // 3. İşlemlerin tamamlanmasını bekle
        await Task.WhenAll(tasks);
    }

    public async Task<List<Product>> SuggestAsync(string prefix)
    {
        List<object> args = [AutocompleteDictionaryKey, prefix];

        if (prefix.Length >= 3) // Performans: Çok kısa sorgularda (1-2 harf) maliyeti düşürmek için Fuzzy modu kapatılabilir.
        {
            args.Add("FUZZY");
        }

        args.Add("WITHPAYLOADS");
        args.Add("MAX");
        args.Add("5");

        RedisReply[] products = await connection.ExecuteAsync("FT.SUGGET", [.. args]);

        if (products == null || products.Length == 0) return [];

        return [..products
            .Where((_, index) => index % 2 == 1) // Sadece payload (tekil indeksler)
            .Select(product => JsonSerializer.Deserialize<Product>(product.ToString()))
            .DistinctBy(p => p.Id) // Tekilleştirme
            .Take(5)];
    }
}

💡 Performans İpucu: Fuzzy Kullanımında Eşik Değeri FT.SUGGET komutunda FUZZY parametresi, Levenshtein mesafesi hesaplaması nedeniyle ek işlemci maliyeti (CPU overhead) yaratır. Özellikle 1 veya 2 karakterlik çok kısa prefix aramalarında, potansiyel eşleşme havuzu çok geniş olacağından bu maliyet katlanarak artar ve gecikmelere (latency) yol açabilir.

Öneri: FUZZY özelliğini koşullu hale getirin. Prefix uzunluğu 3 karakterin altındaysa standart arama yapın; sadece 3 ve üzeri karakterlerde bulanık aramayı devreye alın. Bu yaklaşım, kaynak kullanımı ile kullanıcı deneyimi arasındaki en optimum dengeyi sağlar.

Kullanım Senaryosu

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRedisInfrastructure(builder.Configuration);

var app = builder.Build();

/// <summary>
/// RedisSearch index’lerini oluşturur (startup veya manuel tetikleme).
/// </summary>
app.MapPost("/search/init", async (IProductSearchService service) =>
{
    await service.InitializeIndexAsync();
    return Results.Ok("Index oluşturuldu.");
});

/// <summary>
/// Tip güvenli RedisSearch sorgusu.
/// </summary>
app.MapGet("/products/autocomplete", async (
    string prefix,
    IAutocompleteService service) =>
{
    var result = await service.SuggestAsync(prefix);
    return Results.Ok(result);
});

app.Run();

Sonuç: Dengeli Bir Mimari

RediSearch, hem kurulum basitliği hem de in-memory çalışmanın getirdiği o agresif hızıyla modern stack’lerde kendine sağlam bir yer edindi. Özellikle Redis OM gibi kütüphanelerle .NET tarafındaki geliştirici deneyimi de gayet tatmin edici.

Burada benim şahsi favorim ve önerim Hibrit Mimari yaklaşımı:

• Arka plandaki log analizleri, devasa veri ambarları veya karmaşık raporlamalar için Elasticsearch gücünü koruyor, orada macera aramaya gerek yok.
• Ama iş, kullanıcının birebir etkileşime girdiği “Arama Kutusu” veya anlık filtrelemelere gelince RediSearch kullanımı değerlendirilmelidir.

Bu kurgu, hem altyapı maliyetlerini optimize etmemizi sağlıyor hem de kullanıcıya o beklediği ışık hızında deneyimi sunuyor.

GitHub - cihatsolak/net10-redisearch-dotnet-integration: A .NET 10-based integration project demonstrating how to use RediSearch with Redis in modern .NET applications. It focuses on indexing, querying, and full-text search capabilities, providing practical examples and a clean setup for learning and experimentation.

Otomatik tamamlama, kullanıcı deneyiminin sadece ilk adımıydı. RediSearch ile milyonlarca döküman içinde milisaniyeler süren aramalar yapmak, coğrafi (geo-spatial) filtrelemeler uygulamak ve veriden anlamlı raporlar çıkarmak mümkün.

Bir sonraki yazımda, RediSearch’ün komut setini (FT.CREATE, FT.SEARCH, FT.EXPLAIN) masaya yatıracak ve gerçek bir arama motorunun mimarisini kurgulayacağız.

Görüşmek üzere.

• Redis Query Engine
• GitHub - redis/redis-om-dotnet: Object mapping, and more, for Redis and .NET
• redis/redis-stack - Docker Image
• Elastic fundamentals | Elastic Docs
• Inverted index - Wikipedia
• Redis University

RediSearch ile Real-Time Search Mimarisi ve .NET Entegrasyonu was originally published in Intertech on Medium, where people are continuing the conversation by highlighting and responding to this story.

New Era in .NET API Documentation with Scalar

Modern .NET ekosisteminde API dokümantasyonu, yazılım geliştirme sürecinin vazgeçilmez bir parçası haline geldi. OpenAPI standartları sayesinde API’ler daha anlaşılır oluyor; bu da ekip içi iletişimi güçlendiriyor, test otomasyonunu kolaylaştırıyor ve istemci kütüphanelerinin otomatik olarak üretilmesini sağlıyor.

OpenAPI Nedir ve Neden Önemlidir?

OpenAPI, API’lerin yapılandırılmış ve standart bir biçimde tanımlanmasını sağlayan bir spesifikasyondur. JSON veya YAML formatında yazılan bu doküman; endpoint’leri, istek ve yanıt modellerini, yetkilendirme yöntemlerini ve hata kodlarını tanımlar. Böylece:

1️ API geliştiriciler ve kullanıcılar ortak bir anlaşmaya sahip olur.

2️ Kod üretme, test ve dokümantasyon otomasyonu kolaylaşır.

3️ Araçlar tarafından interaktif dokümanlar üretilebilir.

Özetle OpenAPI, API yaşam döngüsünü hızlandıran ve standartlaştıran evrensel bir dildir.

Scalar Nedir?

Scalar, OpenAPI dokümanlarını modern, hızlı ve kullanıcı dostu bir arayüzle sunmak için geliştirilmiş açık kaynaklı bir araçtır. Swagger UI’a göre daha hafif, daha şık ve mobil uyumlu olmasıyla dikkat çeker.

Scalar, .NET API dokümantasyonu için hızlı yükleme süresiyle dikkat çeker; özellikle büyük projelerde minimal kaynak kullanımı sayesinde önemli bir performans avantajı sağlar. Duyarlı tasarımı sayesinde her cihazda sorunsuz görüntülenebilir, bu da geliştiricilerin mobil ortamlarda bile dokümantasyona kolayca erişmesini mümkün kılar. Entegre “Try-it-now” özelliği ile geliştiriciler, belgeler üzerinden doğrudan API çağrıları yaparak test süreçlerini hızlı ve interaktif bir şekilde gerçekleştirebilir. Ayrıca tema ve arayüz ayarlarının kolayca özelleştirilebilmesi sayesinde, Scalar farklı kurumsal kimliklere rahatlıkla uyum sağlayabilir.

Scalar’ı ASP.NET Core Projesinde Kullanmak

Scalar’ı kullanmaya başlamak için projenize Microsoft.AspNetCore.OpenApiveScalar.AspNetCore
NuGet paketlerini ekleyin. Ardından Program.cs dosyanızda OpenAPI ve Scalar ayarlarını yapın.

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddOpenApi();

var app = builder.Build();

app.MapOpenApi();
app.MapScalarApiReference();

Bu basit kurulumla /scalar endpoint’i üzerinden şık bir dokümantasyona sahip olursunuz.

• Microsoft.AspNetCore.OpenApi 9.0.6
• Scalar.AspNetCore 2.4.13

Güvenlik ve Yetkilendirme

Bearer token (JWT) gibi yaygın güvenlik şemalarını Scalar dokümantasyonuna entegre etmek kolaydır. Konfigürasyonlarınızı aşağıdaki gibi yapabilirsiniz:

builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddJwtBearer(JwtBearerDefaults.AuthenticationScheme,
    options =>
    {
        options.TokenValidationParameters = new TokenValidationParameters
        {
        };
    });


builder.Services.AddOpenApi("v1", options =>
{
    options.AddDocumentTransformer<BearerSecuritySchemeTransformer>(); //JWT
});

public sealed class BearerSecuritySchemeTransformer(IAuthenticationSchemeProvider authenticationSchemeProvider)
: IOpenApiDocumentTransformer
{
    public async Task TransformAsync(OpenApiDocument document, OpenApiDocumentTransformerContext context, CancellationToken cancellationToken)
    {
        var authenticationSchemes = await authenticationSchemeProvider.GetAllSchemesAsync();
        if (!authenticationSchemes.Any(scheme => scheme.Name == JwtBearerDefaults.AuthenticationScheme))
            return;

        AddBearerSecurityScheme(document);
        ApplySecurityRequirements(document);
    }

    private static void AddBearerSecurityScheme(OpenApiDocument document)
    {
        document.Components ??= new OpenApiComponents();
        document.Components.SecuritySchemes ??= new Dictionary<string, OpenApiSecurityScheme>();

        document.Components.SecuritySchemes[JwtBearerDefaults.AuthenticationScheme] = new OpenApiSecurityScheme
        {
            Type = SecuritySchemeType.Http,
            Scheme = "bearer",
            In = ParameterLocation.Header,
            BearerFormat = "JWT",
            Reference = new OpenApiReference
            {
                Id = JwtBearerDefaults.AuthenticationScheme,
                Type = ReferenceType.SecurityScheme
            }
        };
    }

    private static void ApplySecurityRequirements(OpenApiDocument document)
    {
        foreach (var operation in document.Paths.Values.SelectMany(path => path.Operations.Values))
        {
            operation.Security ??= [];
            operation.Security.Add(new OpenApiSecurityRequirement
            {
                [new OpenApiSecurityScheme
                {
                    Reference = new OpenApiReference
                    {
                        Id = JwtBearerDefaults.AuthenticationScheme,
                        Type = ReferenceType.SecurityScheme
                    }
                }] = Array.Empty<string>()
            });
        }
    }
}

Scalar aynı zamanda farklı güvenlik şemaları için kolayca genişletilebilir. Örneğin API key, OAuth2 gibi protokolleri destekler. Böylece dokümantasyon hem kapsamlı hem güvenli olur.

Versiyonlama Desteği

Kurumsal projelerde API versiyonlaması kaçınılmazdır. Scalar, farklı OpenAPI dokümanlarını versiyonlara göre ayırmanı ve aynı kullanıcı arayüzü altında birden fazla API versiyonunu sunmanı destekler. Bu özellik sayesinde, hem geçmiş versiyonları koruyabilir hem de yeni versiyonları aşamalı olarak yayınlayabilirsin.

Program.cs içinde versiyonlara göre Scalar yapılandırması:

// Using AddDocument with different route patterns
app.MapScalarApiReference(options =>
{
    options
        .AddDocument("v1", "Production API", "api/{documentName}/spec.json")
        .AddDocument("v2-beta", "Beta API", "beta/openapi.json");
});

// Using AddDocuments with string array (uses default route pattern)
string[] versions = ["v1", "v2"];
app.MapScalarApiReference(options => options.AddDocuments(versions));

// Using AddDocuments with ScalarDocument objects
var documents = new[]
{
    new ScalarDocument("v1", "Production API", "api/v1/spec.json"),
    new ScalarDocument("v2-beta", "Beta API", "beta/openapi.json"),
    new ScalarDocument("v3-dev", "Development API", "dev/{documentName}.json")
};
app.MapScalarApiReference(options => options.AddDocuments(documents));

AddDocument metodundaki routePattern parametresi, OpenAPI dokümanının hangi URL yolunda sunulacağını özelleştirmeni sağlar. Eğer belirtilmezse, varsayılan olarak ayarlardaki global OpenApiRoutePattern değeri kullanılır. Bu desen içinde {documentName} yer tutucusu bulunabilir ve bu kısım doküman adıyla değiştirilir.

Tasarım/Tema Desteği

Scalar, geliştiricilere kullanıcı arayüzünü kendi marka kimliğine göre özelleştirme imkânı verir. Varsayılan tema seçeneklerinin ötesine geçerek kendi CSS/JS dosyalarını entegre edebilir, logo, font ve renk paletini kontrol edebilirsin.

Hazır temaları kullanmak:

app.MapScalarApiReference(opt =>
{
    opt.WithTitle("Okyanus Tonlarında API Dokümantasyonu")
       .WithTheme(ScalarTheme.BluePlanet);
});

Özelleştirilmiş CSS/JS kullanmak:

app.MapScalarApiReference(opt =>
{
    opt.WithTitle("Intertech API Dokümantasyonu")
       .WithTheme(ScalarTheme.Default)
       .WithCustomCss("/assets/scalar/custom-style.css")
       .WithDefaultHttpClient(ScalarTarget.CSharp, ScalarClient.HttpClient);
});

wwwroot/assets/scalar/custom-style.css

body {
    font-family: 'Segoe UI', sans-serif;
    background-color: #1e1e2f;
    color: #e0e0e0;
}

Container ve Çoklu Ortamlarda Scalar Kullanımı

Özellikle Docker ve Kubernetes gibi konteyner ortamlarında, API servisleriniz farklı portlarda çalışabilir. Scalar’ın MapScalarApiReference metodu, ortam değişkenleri ile portları dinamik olarak algılayabilir ve doğru OpenAPI endpoint’lerini otomatik oluşturur.

app.MapScalarApiReference(opt =>
{
    List<ScalarServer> servers = new();
    string? httpsPort = Environment.GetEnvironmentVariable("ASPNETCORE_HTTPS_PORT");
    if (httpsPort != null)
        servers.Add(new ScalarServer($"https://localhost:{httpsPort}"));

    string? httpPort = Environment.GetEnvironmentVariable("ASPNETCORE_HTTP_PORT");
    if (httpPort != null)
        servers.Add(new ScalarServer($"http://localhost:{httpPort}"));

    opt.Servers = servers;
    opt.Title = "Containerize API Dokümantasyonu";
    opt.ShowSidebar = true;
});

Bu, çoklu servislerin bulunduğu karmaşık projelerde bile dokümantasyonun her zaman erişilebilir ve güncel kalmasını sağlar.

Scalar Arayüzünü Otomatik Açmak

launchSettings.json dosyasındaki launchUrl ayarını scalar olarak değiştirerek, uygulama çalıştığında otomatik olarak Scalar UI açılmasını sağlayabilirsiniz.

"launchUrl": "scalar"

Değerlendirme

OpenAPI ile API’lerinizi standartlaştırmak artık neredeyse zorunlu bir gereklilik. Scalar ise bu dokümantasyonları modern, hızlı ve kullanıcı dostu şekilde sunarak geliştirici deneyimini üst seviyeye çıkarıyor.

Özellikle performans, mobil uyumluluk ve kolay özelleştirilebilirlik Scalar’ı cazip kılıyor. Container ortamlarında portları otomatik algılayabilmesi büyük projelerde konfor sağlıyor.

Bu sebeplerle, Swagger yerine Scalar’ı tercih etmek yeni nesil ASP.NET projeleri için sağlam bir seçenek olarak öne çıkıyor.

• Scalar - Document, Discover and Test APIs
• scalar/integrations/aspnetcore/README.md at main · scalar/scalar
• OpenAPI Initiative - The OpenAPI Initiative provides an open source, technical community, within which industry participants may easily contribute to building a vendor-neutral, portable and an open specification for providing technical metadata for REST APIs - the "OpenAPI Specification" (OAS).
• .NET Integration
• Swagger is Dead? Here's the Alternative! - codewithmukesh
• "From Swagger to Scalar: The .NET 9 Evolution Begins"

Scalar ile .NET API Dokümantasyonunda Yeni Dönem was originally published in Intertech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Management 3.0 Nedir?

Management 3.0, Jurgen Appelo tarafından 2010 yılında geliştirilmiş, son yıllarda ülkemizde popülerliğini arttırmaya başlamış modern bir liderlik ve yönetim modelidir. Bu model, çalışanları organizasyonun en önemli varlığı olarak görüyor ve onların mutluluğunu, motivasyonunu ve etkinliğini ön planda tutuyor.

Management 3.0, geleneksel yönetim anlayışlarının aksine, daha fazla iş birliği ve insan odaklı bir yaklaşımı teşvik ediyor. Bu model, çalışanların potansiyellerini en iyi şekilde kullanmalarını sağlamak amacıyla liderlerin destekleyici ve yönlendirici bir rol üstlenmesini vurguluyor.

Management 3.0’ın sağladığı en büyük avantajlardan biri, ekiplerin kendi kendine yönetilme ve problem çözme becerilerini geliştirmesidir. Özellikle çevik organizasyonlarda, bu modelin getirdiği özerklik ve destekleyici yaklaşımlar, ekiplerin daha yaratıcı ve verimli sonuçlar üretmelerine olanak tanıyor.

Management 1.0 ve 2.0’ın Ötesinde: Neden Management 3.0?

Yönetim anlayışlarını değerlendirirken, Management 1.0 ve 2.0 modellerine göz atmak faydalı olacaktır.

İş hayatımda Management 1.0, 2.0 ve 3.0 yaklaşımlarını benimsemiş farklı liderlerle çalışma şansım oldu. Bu liderlik tarzlarının ekip içindeki etkileşimleri, sorumluluk alma biçimlerini ve karar süreçlerini nasıl etkilediğini bizzat deneyimledim.

Management 1.0: Geleneksel yönetim tarzıdır. Katı bir hiyerarşik yapı vardır; lider emir verir, çalışan uygular. Lider başarıyı kendisine, başarısızlığı ise çalışanlara yazar. İnsanlar birer “kaynak” olarak görülür. Bu yaklaşımda inisiyatif yoktur, çalışanlar sadece verilen işi yapar. Yaratıcılığı ve katılımı körelten bir sistemdir.

Management 1.0 yaklaşımına yakın bir yöneticimle çalıştığım dönemde, ekip içindeki en basit kararların bile mutlaka onun onayından geçmesi gerekiyordu. Hatta sadece takım içinde kalacak bir takım anlaşması afişinde kullanılan fonta ve metne dahi müdahale ettiğini hatırlıyorum. O an içimden şöyle geçirmiştim: “Bu kadar küçük bir konuda bile bu kadar kontrol varsa, acaba bu sadece bana mı özel bir tutum, yoksa tüm takıma karşı aynı şekilde mi davranılıyor?” Bu sorgulama bile aslında başlı başına o liderlik yaklaşımının yarattığı güvensizlik ortamının bir göstergesiydi.

Management 2.0: Modern araç ve yöntemler (örneğin performans değerlendirme sistemleri, anketler, ödüllendirme sistemleri vb.) devreye girmiştir. Ancak bunlar genellikle yüzeyde kalır. Çalışanlara danışılıyor gibi görünse de, gerçek güç yine yöneticidedir. Yani “görüş alınıyor” ama “karar alma” yetkisi devredilmez. Bu modelde lider, eski hiyerarşiyi korur ama modern süslemelerle kaplar.

Management 2.0 yaklaşımına yakın bir liderle çalıştığım dönemde, kendimi daha rahat hissettiğim dönemler oldu, özellikle işler yolunda giderken ve kararlarda daha fazla söz hakkım olduğunda. Fikirlerim değer buluyordu ve ekip olarak daha açık bir iletişim içindeydik. Ancak işler karmaşıklaşmaya başladığında ve bir kriz anı yaşandığında, bir anda karar mekanizmasından dışlanmış hissediyordum. Stratejiyle ilgili önemli hatalar fark ettiğimde, bu durumu dile getirdiğimde bana çoğu zaman “Bu liderin sorumluluğunda” deniyordu. Takım olarak doğru yolda olmadığımızı, uçuruma doğru gittiğimizi hissettiğimizde bile, tek başına liderin kararlarına odaklanılmak zorunda kalıyorduk. Bu deneyim, aslında görünürde daha modern ve katılımcı bir yapının, temelde yine liderin kontrolünde olduğunu bana gösterdi.

Management 3.0: Gerçek bir zihniyet dönüşümünü temsil eder. Yönetim sadece yöneticinin işi değildir; herkesin katkısı önemlidir. Liderler, sistemi yönetir; insanları değil. Ekiplerin kendi kararlarını verebilecekleri bir ortam kurulur. Yetki devri yapılır, güven ortamı yaratılır. Yaratıcılık, iş birliği ve sürekli gelişim teşvik edilir.

Management 3.0 yaklaşımına sahip bir liderle çalıştığımda ise tamamen farklı bir deneyim yaşadım. Lider, karar alma süreçlerine katılımı teşvik ediyor ve hata yapma konusunda güvenli bir ortam sunuyordu. Bu ortamda hatalarım beni korkutmak yerine, onlardan öğrenebileceğimi ve gelişebileceğimi hissettim. Zamanla, belirli konularda özgüvenim arttı ve kendi başıma bağımsız kararlar alabileceğim bir profesyonel ortamda çalışmak, hem benim hem de ekip arkadaşlarımın gelişimini doğrudan destekleyen bir deneyim oldu.

Agile ile Management 3.0'ın Bağı

Agile ve Management 3.0 arasında güçlü bir bağ bulunuyor, çünkü her iki yaklaşım da aynı temel hedeflere yöneliyor: özerklik, iş birliği ve sürekli gelişim. Agile, ürün geliştirme süreçlerinde çevikliği, adaptasyonu ve hızlı geri bildirim almayı vurgularken; Management 3.0, bu çevikliği organizasyon genelinde bir kültür haline getirmeyi amaçlar. Agile, daha çok pratikteki yöntemlere odaklanırken, Management 3.0 insan odaklı bir liderlik anlayışı sunarak ekiplerin potansiyellerini en üst düzeye çıkarmayı hedefler. Bu iki yaklaşım bir araya geldiğinde, organizasyonlar sadece daha çevik değil, aynı zamanda daha insan odaklı, katılımcı ve sürdürülebilir bir iş ortamı yaratabilirler. Ekiplerin kendi kararlarını alabilmesi, özgürce fikir paylaşabilmesi ve sürekli gelişime odaklanabilmesi için bu iki yaklaşım mükemmel bir uyum sağlar.

Management 3.0’ın Temel İlkeleri

Management 3.0, çalışanları ve organizasyonları daha etkili ve verimli bir şekilde yönetmek için beş temel ilkeye dayanır. Bu ilkeler, organizasyonel başarıyı destekleyen ve ekiplerin en yüksek potansiyeline ulaşmasını sağlayan stratejileri içerir:

· İnsanları ve Etkileşimlerini Kapsama
Çalışanları işin içine katmak ve onların birbirleriyle etkileşimlerini artırmak, başarılı bir organizasyonun temel taşlarındandır. İnsanların aktif bir şekilde iş sürecine dahil olmaları ve aralarındaki etkileşimlerin güçlendirilmesi, hem motivasyonu hem de iş verimliliğini artırır. Çalışanların fikirlerinin değer görmesi ve saygı duyulması önemlidir. Birlikte çalışma şansı bulduğum ekiplerde, ekip üyelerinin katkılarının takdir ediliyor olmasının onların motivasyonunu ve bağlılıklarını arttırdığını gözlemledim. Çalışanlara, kendi fikirlerini ifade etme ve bu fikirlerin organizasyonel süreçlerde yer bulmasını sağlama fırsatı vermek, onların işlerine daha fazla bağlılık göstermelerini sağlıyor.

· Sistemi İyileştirme
Management 3.0, sadece tek bir takımın değil, sistemde yer alan herkesin iyileştirilmesini hedefler. “Sistem” kelimesinin anlamı, karmaşık ve uyumlu bir yapı olarak görülmelidir. Management 3.0, organizasyonları karmaşık uyumlu sistemler olarak kabul eder. Bu sistemler, birçok bileşenin birbirleriyle etkileşimde bulunduğu ve davranışlarının her zaman öngörülebilir olmadığı yapılardır. İyileştirme, bu sistemlerin sürekli olarak gelişmesini sağlar. Bu ilkeye göre, başarılı olmak için sürekli denemeler yapmalı, denemeler gerçekleştirmeli ve bu deneyimlerden öğrenmeliyiz.

· Tüm Müşterileri Memnun Etme
Müşteriler sadece dış müşterilerle sınırlı değildir. Management 3.0, tüm sistemdeki kişileri müşteri olarak görür. Ekip üyeleri, diğer takımlar, ve paydaşlar da müşteri olarak kabul edilir. Amacımız, tüm bu müşterilerin memnuniyetini sağlamak ve onlara değerli hizmetler sunmaktır. Müşteri memnuniyeti, organizasyonun genel başarısı için kritik öneme sahiptir.

· İnsanların Değil Sistemin Yönetilmesi
İnsanların davranışlarını değiştirmek zordur; ancak ortamı değiştirdiğinizde, insanlar bu yeni ortama uyum sağlama eğilimi gösterirler. Management 3.0, insanların kendilerini yönetebileceği bir ortam yaratmayı amaçlar. Bu, liderlerin, organizasyonel sistemi beslemek ve yönlendirmekle yükümlü olduğu anlamına gelir. Sistemi iyileştirmek ve desteklemek, çalışanların kendi kendilerini yönetmelerine olanak tanır.

· İş birliği ile Çalışma
Hızla değişen ve karmaşık bir dünyada, bireysel fikirler tek başına yeterli olmayabilir. İş birliği, başarılı bir iş ortamının temelidir. Bu ilkeye göre, ekip üyeleri, liderler ve diğer paydaşlar birlikte çalışmalı ve ortak çözümler üretmelidir. Yönetici olarak, iş birliğini teşvik eden ve destekleyen bir sistem yaratmalısınız. Bu ilkeye yardımcı olabilecek bazı yöntemler şunlardır: Takım Anlaşması Kanvası ve Takım Yetkinlik Matrisi. Bu araçlar, ekip içindeki iş birliğini artırır ve ortak hedeflere ulaşmayı kolaylaştırır. Önümüzdeki yazılarda bu teknikleri anlatıyor olacağım.

Management 3.0 Kullanım Örnekleri

Management 3.0, birçok şirket tarafından benimsenmiş ve etkili sonuçlar elde edilmiştir. Örneğin, Brezilyalı şirket AmbevTech, Management 3.0’ı benimsedikten bir yıl sonra ülkede çalışmak için en iyi yer haline gelmiş ve müşteri memnuniyetini %78 oranında artırmıştır. İspanyol yazılım şirketi Keepler de Management 3.0 kavramlarını uyguladıktan sonra kendi kendine yeten ekipler oluşturma konusunda başarılı olmuştur. Bu örneklerin detaylı anlatımlarının olduğu blog yazılarını paylaşacağım.

Management 3.0’ı Öğrenme İçin Kaynak Önerilerim

Management 3.0’ın prensiplerini daha iyi anlamak ve uygulamak isteyenler için bazı kaynakları önereceğim:

• Ana Kaynak: “Management 3.0: Leading Agile Developers, Developing Agile Leaders”, Jurgen Appelo’nun kaleme aldığı bu kitap, Management 3.0 modelinin temel ilkelerini ve uygulama stratejilerini kapsamlı bir şekilde ele alır. Kitap, liderlerin ve organizasyonların bu modern yönetim yaklaşımını nasıl benimseyebileceğine dair pratik bilgiler ve örnekler sunar. Yönetim tarzınızı dönüştürmek ve ekiplerinizin potansiyelini en üst düzeye çıkarmak için mükemmel bir başlangıçtır.
• Web Sitesi:
  https://management30.com/ : Management 3.0’ın resmi web sitesi, konuyu anlamak ve uygulamak için zengin bir içerik sunar. Burada blog yazıları, video röportajlar, interaktif webinar’lar ve başarı hikayeleri gibi kaynaklar bulabilirsiniz. Ayrıca, güncel gelişmeleri takip etmek ve uygulamaları hakkında daha fazla bilgi edinmek için bu siteyi düzenli olarak ziyaret edebilirsiniz.
• Örnek Vakalar:
  https://management30.com/experience/case-studies/keepler/ https://management30.com/experience/case-studies/ambevtech-technological-hub-brazil/
• Youtube Kanalı: Management 3.0’ın resmi Youtube kanalı, konuyla ilgili çeşitli video içerikleri sunar.
  https://www.youtube.com/watch?v=T9d8w-OG-Fk&list=PLHXDFUoljQxByuXvajagqmmPjmERFIy0f

Yeni Nesil Liderler için Yol Haritası: Management 3.0 was originally published in Intertech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Tarih ve saat verilerini yönetmek, uygulamalarda doğru zaman damgaları, tarihsel kayıtlar ve zaman dilimleri gibi hassas bilgilerin işlenmesi açısından kritik bir rol oynar. Bu tür işlemler için C#’ta iki ana veri tipi vardır: DateTime ve DateTimeOffset. Her ikisi de tarihi ve zamanı temsil eder, ancak zaman dilimleri ve saat farkları konusunda farklı yaklaşımlar sunar.

DateTime Nedir?

DateTime, hem tarih hem de saat bilgilerini depolayan bir veri türüdür. Kullanıcının saat dilimini belirtmesine bağlı olarak, UTC (Koordinatlı Evrensel Zaman) veya yerel saat olarak tanımlanabilir. Ancak DateTime, kendisiyle ilişkili bir zaman dilimi bilgisi içermez. Bu durum, farklı zaman dilimlerinde çalışırken veri uyumsuzluklarına ve karışıklıklara neden olabilir.

DateTime now = DateTime.Now;            // Yerel zaman
DateTime utcNow = DateTime.UtcNow;      // UTC zaman
DateTime specificDate = new DateTime(2023, 10, 29, 14, 30, 0); // Belirli bir tarih-saat

• DateTime.Now: Bulunduğunuz yerel saat diliminde anlık zamanı alır.
• DateTime.UtcNow: UTC saatine göre anlık zamanı alır.

DateTime.Now ve DateTime.UtcNow arasındaki fark, tarih ve saat bilgilerinin hangi saat dilimine göre verildiğidir:

• DateTime.Now: Sistemin yerel saat dilimine göre geçerli tarih ve saati verir. Bulunduğunuz coğrafi konuma göre saati belirler, yani bilgisayarın saat dilimi ayarlarını kullanır.
• DateTime.UtcNow: UTC (Coordinated Universal Time) saat dilimine göre tarih ve saati verir. UTC, dünyada herkesin aynı referans noktası olarak kabul ettiği saat dilimidir ve yerel saat diliminden bağımsızdır. Örneğin, Türkiye'deki DateTime.Now ile UTC arasındaki fark normalde yaz saati uygulanmıyorsa +3 saat olur.

UtcNow Neye Göre Belirleniyor?

DateTime.UtcNow, bilgisayarın veya sunucunun dahili saatini UTC referans noktasına göre alır. Sistem zamanı internetten veya yerel bir sunucudan otomatik olarak senkronize ediliyorsa, bu saat de düzenli olarak UTC'ye göre güncellenir. UTC saat dilimi dünya genelinde standart kabul edildiğinden, farklı saat dilimlerindeki sistemlerin birbirleriyle uyumlu çalışmasını sağlar.

DateTimeOffset Nedir?

DateTimeOffset, tarih ve saat bilgisini bir zaman dilimi ofsetiyle (UTC'ye göre fark) birlikte saklar. Böylece belirli bir saatin UTC'ye göre saat farkını içerir. DateTimeOffset, özellikle zaman dilimlerinin farklı olduğu uygulamalarda (örneğin uluslararası projeler) veri uyumluluğunu korumak için daha güvenilir bir seçenek sunar.

DateTimeOffset now = DateTimeOffset.Now;              // Yerel zaman ve ofset
DateTimeOffset utcNow = DateTimeOffset.UtcNow;        // UTC zaman ve ofset 0
DateTimeOffset specificDateWithOffset = new DateTimeOffset(2023, 10, 29, 14, 30, 0, TimeSpan.FromHours(3)); // +03:00 ofseti ile tarih-saat

• DateTimeOffset.Now: Anlık zamanı ve UTC'ye göre ofsetini alır.
• DateTimeOffset.UtcNow: UTC zamanını ve ofsetini alır.

DateTime ve DateTimeOffset Karşılaştırması

Ne Zaman Hangi Tür Kullanılmalı?

Yerel Tarih ve Saat Gerektiğinde: Sadece yerel bir saat ve tarihe ihtiyaç duyuyorsanız (örneğin, takvimde gün seçimi) DateTime kullanımı yeterli olacaktır.

Uluslararası Zaman Dilimleriyle Çalışırken: Farklı bölgelerde zaman dilimi farklarını yönetmek istiyorsanız DateTimeOffset tercih edilmelidir.

Kodlama Örnekleri ve Senaryolar

Örnek 1: UTC Zamanı ile İşlem Yapma

UTC zamanına göre bir tarih-saat saklamak istediğinizde DateTime veya DateTimeOffset türleri ile nasıl çalışabileceğinizi görelim:

// DateTime ile UTC Zaman
DateTime utcTime = DateTime.UtcNow;

// DateTimeOffset ile UTC Zaman
DateTimeOffset utcTimeOffset = DateTimeOffset.UtcNow;

Örnek 2: Zaman Dilimleri Arasında Fark Hesaplama

İki tarih-saat arasındaki farkı hesaplamak DateTime ve DateTimeOffset ile mümkündür, ancak DateTimeOffset daha doğru sonuç verir çünkü ofset bilgilerini korur.

DateTimeOffset startTime = new DateTimeOffset(2023, 10, 29, 10, 0, 0, TimeSpan.FromHours(-5));
DateTimeOffset endTime = new DateTimeOffset(2023, 10, 29, 15, 0, 0, TimeSpan.FromHours(0));

// Fark hesaplama
TimeSpan difference = endTime - startTime;
Console.WriteLine($"Fark: {difference.TotalHours} saat"); // Çıktı: 10 saat

DateTimeOffset ve DateTime Seçiminde Önemli Noktalar

Global Uygulamalar: Kullanıcılar farklı zaman dilimlerinde ise DateTimeOffset tercih edilmelidir.

Yerel Uygulamalar: Sadece yerel zaman gereksinimlerinde DateTime kullanımı daha basit ve performanslı olabilir.

Zaman Dilimi Uyumsuzluklarından Kaçınma: Farklı saat dilimlerinde çalışan ekipler veya kullanıcılar için, zaman dilimi ofsetini içeren DateTimeOffset daha az hata ve uyuşmazlık sağlar.

Time Zone Desteği ile Göreli Zaman Gösterimi

Global uygulamalarda tarih/saat verilerinin tutarlı yönetimi için UTC formatı kullanılmalıdır. Ürün eklenme zamanı gibi bilgileri gösterirken, UTC’de saklanan veriler kullanıcı saat dilimine çevrilerek gösterilmelidir.

JavaScript ile kullanıcının saat dilimi bilgisi alınabilir:

const timeZone = Intl.DateTimeFormat().resolvedOptions().timeZone;

Bu bilgi her istekle birlikte örneğin bir HTTP header olarak backend’e gönderilmelidir. Aşağıdaki örnek, gelen Time-Zone bilgisine göre göreli zaman hesaplaması yapar:

[HttpGet("product-time-ago")]
public IActionResult GetProductTimeAgo([FromHeader(Name = "Time-Zone")] string timeZoneId)
{
    DateTime createdAtUtc = new DateTime(2025, 4, 19, 10, 0, 0, DateTimeKind.Utc);

    TimeZoneInfo timeZone;
    try
    {
        timeZone = TimeZoneInfo.FindSystemTimeZoneById(timeZoneId);
    }
    catch
    {
        timeZone = TimeZoneInfo.Utc;
    }

    DateTime userNow = TimeZoneInfo.ConvertTimeFromUtc(DateTime.UtcNow, timeZone);
    DateTime userCreatedAt = TimeZoneInfo.ConvertTimeFromUtc(createdAtUtc, timeZone);
    var diff = userNow - userCreatedAt;

    string result = diff.TotalMinutes < 1 ? "az önce eklendi"
                 : diff.TotalMinutes < 60 ? $"{(int)diff.TotalMinutes} dk önce eklendi"
                 : diff.TotalHours < 24 ? $"{(int)diff.TotalHours} saat önce eklendi"
                 : $"{(int)diff.TotalDays} gün önce eklendi";

    return Ok(result);
}

Bu yapı sayesinde zaman bilgisi, her kullanıcıya kendi lokal saatine göre doğru biçimde gösterilir.

Sonuç

DateTime ve DateTimeOffset, doğru senaryolarda kullanıldıklarında güçlü ve işlevsel veri türleridir. Yerel bir saati temsil etmek için DateTime, zaman dilimleriyle uyumlu veriler oluşturmak ve saklamak için DateTimeOffset tercih edilmelidir. İki tür arasında doğru tercihi yapmak, uygulamanızın zaman verisi yönetimindeki doğruluğunu ve uyumluluğunu artırır.

• Dates, times, and time zones - .NET
• How to change time zone for an asp.net application
• Convert DateTime to user's time zone with Blazor in .NET 8 - Gérald Barré
• C# DateTime.Now vs DateTime.UtcNow: Differences and Use Cases
• Customize Application Time Zone with TimeProvider

Global Uygulamalarda Doğru Zaman Yönetimi was originally published in Intertech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Roslyn: The Modern Compiler Platform for .NET

Roslyn, Microsoft’un .NET uygulamaları için geliştirdiği, güçlü ve esnek bir derleyici platformudur. .NET için Roslyn projesi, sadece bir derleyici değil, aynı zamanda C# ve Visual Basic (VB.NET) dillerinin işlenmesini ve analiz edilmesini sağlayan geniş bir API seti sunar. Bu özellikler sayesinde, geliştiriciler derleyici seviyesinde analiz ve dönüştürme işlemlerini doğrudan projelerinde gerçekleştirebilirler.

Roslyn Nedir?

Roslyn, C# ve VB.NET dillerini derlemek için kullanılan açık kaynaklı bir .NET Compiler Platformudur. Geliştiricilere, derleme sürecinin her aşamasına erişim sağlayarak, dil düzeyinde analiz ve dönüştürme işlemlerini mümkün kılar. Roslyn, hem derleme işlemi için gerekli araçları sağlar, hem de C# ve VB.NET dil yapısına erişim sunarak kod analizi, yeniden yazma ve oluşturma gibi işlemleri mümkün hale getirir.

Roslyn, şu bileşenlerden oluşur:

• Parser: Kodları analiz eder ve kodun yapısını oluşturan sözdizimi ağacını (syntax tree) çıkarır.
• Semantic Model: Kodun anlamsal yapısını oluşturur ve sembol bilgilerini sağlar.
• Code Generation: Kodun yürütülebilir dosyalar (DLL veya EXE) haline dönüştürülmesini sağlar.
• Compilation API: Derleme işlemlerini yönetir ve özelleştirme seçenekleri sunar.

Roslyn’in Özellikleri

Roslyn’in derleyici ve analiz özellikleri, hem derleme sürecinde hem de geliştirme ortamında kullanıcılara esneklik sağlar.

a. Syntax Tree (Sözdizimi Ağacı)
Roslyn, her bir kod bloğunu sözdizimsel düğümlere ayırarak bir syntax tree oluşturur. Bu sayede geliştiriciler, kodun yapısal analizi için her bir ifadeye, deyime ve öğeye erişebilir.

Örnek:

using Microsoft.CodeAnalysis.CSharp;
using Microsoft.CodeAnalysis;

SyntaxTree tree = CSharpSyntaxTree.ParseText("int x = 10;");
var root = tree.GetRoot();
Console.WriteLine(root.ToString()); // int x = 10;

Microsoft.CodeAnalysis.CSharp 4.11.0

b. Semantic Model (Anlamsal Model)
Anlamsal model, bir kodun sözdizimsel yapısının ötesine geçerek değişken, tür ve metot gibi semboller hakkında bilgi sağlar. Bu model, değişkenlerin kapsamı, tip bilgisi, metot çağrıları ve diğer dil özellikleri hakkında detaylı bilgi sunar.

c. Code Analysis (Kod Analizi)
Roslyn, statik kod analizi yapabilme yeteneği sunar. Bu sayede kod kalitesini artırmak, potansiyel hataları yakalamak ve en iyi uygulamaları sağlamak için analiz işlemleri yapılabilir.

d. Refactoring (Kod Yeniden Yapılandırma)
Roslyn, IDE’lerde kodu yeniden düzenleme (refactoring) işlemleri için kullanılabilir. Örneğin, bir değişken adını değiştirmek veya bir metot çağrısını daha okunaklı hale getirmek gibi işlemler Roslyn ile yapılabilir.

Roslyn ile Derleme Süreci

Roslyn, bir C# veya VB.NET kodunu derlemek için aşağıdaki adımları takip eder:

1. Kodun Parse Edilmesi (Parse)
   Kod, parse edilir ve bir syntax tree oluşturulur. Bu aşamada, kodun yapısal hataları tespit edilebilir.
2. Anlamsal Modelin Oluşturulması (Semantic Analysis)
   Syntax tree üzerinde bir semantic analysis yapılır ve semboller tanımlanır. Kodun anlamı değerlendirilir ve tür bilgisi gibi detaylar eklenir.
3. Optimizasyon ve Dönüştürme
   Kod optimize edilir ve derleme için uygun bir ara kod (intermediate code) haline getirilir.
4. Yürütülebilir Kod Üretimi (Emit)
   Kod, yürütülebilir bir biçime (örneğin, bir DLL veya EXE dosyasına) dönüştürülür.

Bu süreç, Microsoft.CodeAnalysis namespace’i altındaki Compilation sınıfları ile yönetilebilir ve özelleştirilebilir.

Roslyn Kullanım Senaryoları

a. IDE İçin IntelliSense ve Kod Tamamlama
Roslyn, Visual Studio gibi IDE’lerde IntelliSense ve kod tamamlama özellikleri için kullanılmaktadır. Syntax tree ve semantic model sayesinde, kod yazarken anında önerilerde bulunur ve olası hataları gösterir.

b. Kod Analiz Araçları
Roslyn, statik kod analizi araçları oluşturmak için mükemmel bir altyapı sunar. Örneğin, kurumsal bir uygulamada belirli güvenlik standartlarının uygulanıp uygulanmadığını analiz eden özel bir araç geliştirebilir.

c. Refactoring (Kod Yeniden Düzenleme)
IDE’de kod yeniden düzenleme işlemleri yapılırken, Roslyn’in API’leri ile sınıf adlarının değiştirilmesi, metotların yeniden adlandırılması gibi işlemler kolayca gerçekleştirilebilir.

d. Kendi Derleyici ve Analiz Araçlarınızı Geliştirme
Roslyn, tamamen özelleştirilebilir bir derleyici platformu olduğundan, kendi kod dönüştürme veya analiz araçlarınızı geliştirmek için idealdir.

Örnek: Roslyn ile Basit Kod Analizi

Aşağıdaki örnekte, Roslyn kullanarak basit bir statik kod analizi yapacağız. Bu analiz, tüm for döngülerinde int türünde bir sayaç kullanıldığını kontrol eder.

using Microsoft.CodeAnalysis;
using Microsoft.CodeAnalysis.CSharp;
using Microsoft.CodeAnalysis.CSharp.Syntax;
using System.Linq;

class Program
{
    static void Main()
    {
        var code = @"
            using System;
            class Sample
            {
                void Test()
                {
                    for (int i = 0; i < 10; i++) { Console.WriteLine(i); }
                }
            }";

        SyntaxTree tree = CSharpSyntaxTree.ParseText(code);
        var root = tree.GetRoot();

        var forStatements = root.DescendantNodes().OfType<ForStatementSyntax>();

        foreach (var forStatement in forStatements)
        {
            var declaration = forStatement.Declaration;
            if (declaration.Type.ToString() != "int")
            {
                Console.WriteLine("Hata: Sayaç tipi 'int' değil.");
            }
        }
    }
}

Bu kod, for döngüsündeki sayaç değişkeninin int türünde olup olmadığını kontrol eder ve farklı bir tür kullanıldığında hata mesajı verir.

Roslyn’in Avantajları

• Açık Kaynak: Roslyn, GitHub’da açık kaynak olarak sunulmaktadır, bu sayede geliştiriciler tarafından genişletilebilir ve özelleştirilebilir.
• IDE Entegrasyonu: Visual Studio gibi popüler IDE’lere entegre edilmiştir, bu da kod yazma deneyimini geliştirir.
• Esneklik: Syntax ve semantic analiz yapıları sayesinde, farklı kod analizleri ve kod dönüştürme işlemleri yapılabilir.
• Yüksek Performans: Roslyn, yüksek performans gereksinimlerini karşılayacak şekilde optimize edilmiştir.

Roslyn ile İleri Seviye Kod Analizi ve Dönüştürme

Roslyn, sadece basit analizler için değil, aynı zamanda daha karmaşık kod analizleri ve kod dönüştürmeleri için de kullanılabilir. Örneğin:

• Güvenlik Analizleri: Belirli bir kod parçasının güvenlik standartlarına uygun olup olmadığını denetlemek.
• Kendi Dil Özelliklerinizi Eklemek: C# veya VB.NET dil özelliklerini genişletmek ve kendi özel dil kurallarınızı uygulamak.

Sonuç

Roslyn, modern .NET uygulamaları için güçlü ve esnek bir derleyici platformudur. Geliştiricilere, derleyici düzeyinde kontrol sağladığı için kod analizinden kod dönüştürmeye, hata denetiminden performans analizine kadar geniş bir yelpazede uygulama imkânı tanır. Roslyn, yalnızca bir derleyici değil, aynı zamanda .NET ekosisteminde yazılım geliştirme sürecini daha verimli hale getiren güçlü bir araç setidir.

• .NET Compiler Platform SDK'sı (Roslyn API'leri)
• .NET Compiler Platform SDK concepts and object model - C#
• GitHub - dotnet/roslyn: The Roslyn .NET compiler provides C# and Visual Basic languages with rich code analysis APIs.

Roslyn: .NET için Modern Derleyici Platformu was originally published in Intertech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Dağıtılmış sistemlerde, paylaşılan kaynaklara eşzamanlı erişim durumları kritik sorunlara yol açabilir. Veri tutarlılığının korunması, kaynak çakışmalarının önlenmesi ve sistem stabilizesinin sağlanması için etkili bir kilitleme 🔒 mekanizması gereklidir. Redis ve onun üzerinde inşa edilen RedLock algoritması, bu ihtiyacı karşılamak için güçlü bir çözüm sunar.

RedLock Nedir?

RedLock, Redis'in temel kilitleme mekanizmasını kullanarak multi-node yapıdaki dağıtılmış sistemlerde tutarlı kilitleme sağlar. Antirez tarafından tasarlanan bu algoritma, çoklu Redis sunucusunun senkronize çalışmasıyla kilitleme ve kilit serbest bırakma mekanizması sağlar. Redlock, Redis’â dayalı bir dağıtık kilitleme algoritmasıdır ve aşağıdakiler ve benzeri sorunları çözmeyi amaçlar:

🗄️ Veri Tutarlılığı: Aynı anda birden fazla işlemcinin aynı kaynağa erişmesini engeller.

👮🏻 Güvenlik : Redis sunucuları arasında doğru kilitlemeyi sağlar.

📈 Performans: Düşük gecikmeyle etkili kilitleme sağlar.

Redlock algoritması, birden fazla Redis sunucusu ile çalışacak şekilde tasarlanmış olup, dağıtılmış sistemlerde hataya tolerans ve güvenilirlik sağlar. Tek bir sunucu ile uygulanabilir ancak bu, algoritmanın dağıtılmış güvenlik amacını karşılamaz.

GitHub - samcook/RedLock.net: An implementation of the Redlock algorithm in C#

Redlock, dağıtık uygulamalarda işlemlerinizi kilitlemeden yürütmeye çalıştığınızda karşılaşılan veri tutarsızlığı, kaynak hataları ve performans sorunları gibi sorunları etkili bir şekilde çözerek, kaynakların doğru kullanılmasını ve sistemin tutarlılığını sağlar.

Örnek Kullanım Senaryoları

💬 Mesaj Kuyruğu İşlemleri: Bir mesaj kuyruğunda birden fazla tüketici aynı mesajın işlenmesine çalıştığında kilit mekanizması ile çakışma önlenir.

🚛 Stok Kontrolü: E-ticaret sitelerinde stok kontrolü yaparken, aynı ürünün birden fazla kişiye satılmaması için kilit sistemi kullanılabilir.

⏲️ Scheduled Tasks: Birden fazla sunucu üzerinde zamanlanmış görevlerin tekrar tekrar çalışmasını önlemek için dağıtılmış kilit kullanılabilir.

RedLock.net 2.3.2

RedLock Nasıl Kullanılır?

RedLock kullanımı Redis kütüphaneleri 📚 aracılığıyla kolaylaştırılmıştır. Örneğin StackExchange.Redis ve RedLock.net kütüphaneleri bu işlemleri yönetmek için yaygın olarak kullanılır.

ASP.NET Core uygulamalarında RedLock genellikle Dependency Injection (DI) 💉 yapısı ile entegre edilir. Bu şekilde, merkezi bir Redis bağlantısı ve kilitleme mekanizması kullanılabilir.

1.1 Redis Bağlantısı ve RedLock DI Kullanımı

// Redis bağlantı noktaları
var redisEndpoints = new[]
{
    new RedisConnectionConfiguration { EndPoint = new DnsEndPoint("localhost", 6379) },
    new RedisConnectionConfiguration { EndPoint = new DnsEndPoint("localhost", 6380) },
    new RedisConnectionConfiguration { EndPoint = new DnsEndPoint("localhost", 6381) }
};

// Redlock yapılandırması
var redlockFactory = RedLockFactory.Create(redisEndpoints);
builder.Services.AddSingleton<IRedLockFactory>(redlockFactory);

1.2 Kullanım

public class IntertechService
{
    private readonly IRedLockFactory _redLockFactory;

    public IntertechService(IRedLockFactory redLockFactory)
    {
        _redLockFactory = redLockFactory;
    }

    public async Task PerformTaskWithLockAsync()
    {
        string lockKey = "intertech-service-lock";
        TimeSpan expiry = TimeSpan.FromSeconds(30);

        using var redLock = await _redLockFactory.CreateLockAsync(lockKey, expiry);
        if (redLock.IsAcquired)
        {
            // Kilit alındı, kritik işlem yapılabilir
            Console.WriteLine("Task running with lock.");
        }
        else
        {
            // Kilit otomatik olarak serbest bırakıldı (using bloğu)
            Console.WriteLine("Could not acquire lock.");
        }
    }
}

Wait ve Retry Parametreleri Ne İşe Yarar?

wait ve retry parametreleri, Redis üzerinde dağıtılmış kilit oluşturma işlemi sırasında kilidin alınmasını beklemek ve yeniden denemek için kullanılır.

⌚ WAİT

• Tanım: Kilidi almak için en fazla ne kadar süreyle bekleyeceğinizi belirler.
• Kullanım: Eğer kilit başka bir işlem tarafından tutuluyorsa, bu süre boyunca kilidin serbest bırakılmasını bekler. Belirtilen süre boyunca kilit alınamazsa, kilit alma işlemi başarısız olur.

🔄 RETRY

• Tanım: Kilidi almak için yapılan denemeler arasında ne kadar süre bekleyeceğinizi belirler.
• Kullanım: Eğer bir kilit alınamazsa, belirtilen süre kadar bekledikten sonra yeniden deneme yapılır. Bu süreç, wait süresi dolana kadar devam eder.

string lockKey = "the-thing-we-are-locking-on";
TimeSpan expiry = TimeSpan.FromSeconds(60);
TimeSpan wait = TimeSpan.FromSeconds(10);
TimeSpan retry = TimeSpan.FromSeconds(1);

var redLock = redLockFactory.CreateLock(lockKey, expiry);
if (redLock.IsAcquired)
{
    // Lock acquired
}
else
{
    // Lock not acquired
}

var redLock2 = redLockFactory.CreateLock(lockKey, expiry, wait, retry);
if (redLock2.IsAcquired)
{
    // Lock acquired
}
else
{
    // Lock not acquired
}

Bu satırda:

wait = 10 saniye:

Kilidi almak için en fazla 10 saniye boyunca bekleyecek.

retry = 1 saniye:

Eğer wait süresi içerisinde kilit alınamazsa, 1 saniye bekledikten sonra tekrar deneyecek.

Sonuç:

Eğer 10 saniye içinde kilit alınamazsa (lockKey’e ait farklı bir kilit varsa ve işlem kilidi serbest bırakmazsa), redLock2'e ait kilit alma işlemi başarısız olarak işaretlenecek (redLock2.IsAcquired false olacak).

⚠️⚠️ Redlock instance’ına uzun süreli bir expiry süresi tanısanız bile, using bloğu kullanıldığında kilit, metodun sonunda otomatik olarak serbest bırakılacaktır. Buna dikkat etmeniz önemlidir.

Bu Parametreler (Wait, Retry, Expiry, LockKey) Neden Kullanılır?

Bu mekanizma, kilit yarışını önler ve aynı kaynağı kullanmaya çalışan farklı işlemler arasında koordinasyon sağlar. Özellikle:

• Bir işlemin kilidi hemen alamaması durumunda belli bir süre beklemesi gerekebilir.
• Aşırı yüklenmeyi önlemek için yeniden denemeler arasında bir bekleme süresi bırakılır.

👨🏻‍🏫 Basit Bir Örnek

Bir senaryo düşünelim: E-ticaret platformunuzdaki bir stok güncelleme sistemi, bir ürünün stoğunu birden fazla işlemcinin aynı anda güncellemesini engellemelidir. Bu sorun kilitlenme olmadan çalışırsa, stok değerleri yanlış olabilir/güncellenebilir.

Redlock.net kullanarak bu sorunu çözelim:

static void Main(string[] args)
    {
        // Redis Bağlantıları
        var redisConnections = new[]
        {
            ConnectionMultiplexer.Connect("localhost:6379"),
            ConnectionMultiplexer.Connect("localhost:6380"),
            ConnectionMultiplexer.Connect("localhost:6381")
        };

        using (var redlockFactory = RedLockFactory.Create(redisConnections))
        {
            var resource = "lock:product:123"; // Kilitlenecek kaynak
            var expiry = TimeSpan.FromSeconds(30); // Kilidin yaşam süreci

            using (var redLock = redlockFactory.CreateLock(resource, expiry))
            {
                if (redLock.IsAcquired)
                {
                    // Kritik işlem
                    Console.WriteLine("Stok güncelleniyor...");
                    // Stok güncelleme kodu buraya gelir
                }
                else
                {
                    Console.WriteLine("Kaynak kilitlendi, daha sonra tekrar deneyin.");
                }
            }
        }
    }

Sonuç

Redis ve RedLock algoritması, dağıtılmış sistemlerde kaynak erişimi ve veri tutarlılığını sağlamak için etkili bir çözüm sunar. Kilit alma ve serbest bırakma mekanizmaları, performans ve tutarlılığı bir arada sunar. ASP.NET Core uygulamalarında Redis ve RedLock entegre edilerek, sistem stabilizesi ve veri güvenliği artırılabilir. Dağıtılmış sistemlerde kilitleme mekanizmalarına olan ihtiyacın artmasıyla, RedLock gibi çözümler kritik öneme sahiptir.

• Redis Lock - Redis
• Distributed Locks with Redis + .NET
• RedLock.NET ile Distributed Lock uygulayarak Concurrency durumlarını engelleyin 🔒
• Implementing Distributed Locks with Redis Redlock Algorithm for Dotnet

Dağıtılmış Sistemlerde Redis ve RedLock ile Kilitleme Mekanizmaları was originally published in Intertech on Medium, where people are continuing the conversation by highlighting and responding to this story.

If you’d like to read the content in Turkish, please scroll down. (İçeriği Türkçe olarak okumak isterseniz lütfen aşağı kaydırın.)

[ENG] Dependency Inversion/Inversion of Control Principle

The Dependency Inversion principle is one of the fundamental principles used to manage dependencies in software design. Typically, a class establishes a direct dependency on another class; for instance, the IntertechController class directly uses the IntertechService class. In such cases, the public components of IntertechService are directly accessible by IntertechController, resulting in a tightly coupled relationship between the two classes.

If a method within IntertechService is mistakenly defined as private, it could lead to errors in IntertechController. Similarly, if IntertechService depends on IntertechRepository, even minor changes in IntertechRepository can potentially affect the functionality of IntertechService.

The Dependency Inversion Principle proposes introducing an interface to eliminate this tight coupling. Through this approach, IntertechController does not directly depend on IntertechService but instead interacts with an interface of IntertechService. The class then works with any implementations of this interface. This method adheres to two key principles:

1. High-level modules should not depend on low-level modules. Both should depend on abstractions.
   The high-level module (e.g., IntertechController) should not directly know the low-level modules (e.g., IntertechService). Instead, an abstraction should mediate between them.
2. Abstractions should not depend on details. Details should depend on abstractions.
   The methods defined in the interface should not reveal implementation details. For example, the GetBanks method should not expose specifics about where the data originates. These details should reside within the implementation class (e.g., IntertechService).

The Dependency Inversion Principle improves testability, reduces maintenance costs, and minimizes the impact of future changes on the system by breaking dependencies between modules. For instance, if IntertechController requires IntertechService and it is instantiated directly using the new keyword, any replacement of IntertechService with a different class would necessitate changes in IntertechController. However, if an interface is introduced, IntertechController would only rely on the interface of IntertechService. Consequently, when the implementation class of the interface is replaced, IntertechController remains unaffected.

Dependency Inversion and Inversion of Control (IoC) Are Distinct Concepts
Dependency Inversion asserts that high-level modules should not directly depend on low-level modules; instead, such dependencies should be managed through an interface.

In contrast, Inversion of Control refers to the management of an object’s dependencies and lifecycle by an external control mechanism. IoC is often implemented using Dependency Injection, which enhances flexibility and testability.

Inversion of Control (IoC) Principle
The Inversion of Control (IoC) principle prevents a class A from directly creating an instance of class B using the new keyword. Instead, class B is provided externally through constructor, method, or property injection. In this context, the dependency is referred to as the "dependency object," while class A is called the "dependent object." Although class A needs class B to function, it should not instantiate B directly.

These principles are commonly implemented using one of the most widely used design patterns: Dependency Injection (DI). DI frameworks facilitate the application of these principles. For instance, libraries like Autofac and Ninject act as frameworks by managing dependencies and enabling us to focus on writing our code.

The fundamental feature that differentiates a library from a framework is that, when integrated into a project, a framework uses your code rather than being directly used by your code.

Key Difference Between Framework and Library
A framework is established when a library, once integrated into your project, takes control of your code. In other words, a library that governs the flow of your application code is considered a framework; otherwise, it remains a simple library.

Although it is partially correct to describe a framework as a collection of packages, the defining characteristic lies in how these packages interact with and utilize your code. In this context, Inversion of Control (IoC) and Dependency Injection (DI) frameworks play a crucial role. DI frameworks like Autofac and Ninject simplify dependency management.

Understanding these structures is essential for achieving efficiency and sustainability in software development.

Library: You call it, and the control is in your hands.
Framework: It calls you, and the control is in the framework’s hands.

Single Responsibility Principle (SRP)
The Single Responsibility Principle states that a component (such as a class, module, or microservice) should have only one responsibility. The primary goal of this principle is to ensure that each component performs a single task and does it exceptionally well.

For example, it would violate SRP for a class to handle both email and fax sending functionalities. According to the formal definition, a component should have only one reason to change. This makes software easier to maintain and extend, as only the relevant responsibilities need to be reviewed when a modification is required.

Implementing SRP enhances code readability and simplifies testing, contributing to more sustainable and flexible software.

In conclusion, SRP is a critical principle for reducing complexity and improving manageability in the software development process.

Persistence Ignorance
Persistence Ignorance advocates that domain models, particularly entities and business logic, should have no knowledge of database processes. This principle ensures that entities do not carry details related to any ORM (Object-Relational Mapping) technology, such as Entity Framework Core. Consequently, entities remain unaware of which database technology is being used.
Persistence Ignorance ensures that the design of domain objects aligns with the ideal structure needed to solve business problems, ensuring that persistence processes do not compromise this design. Thus, entities and business logic operate independently of database details, focusing solely on business rules. This approach contributes to a more sustainable, testable, and modular application structure. Ultimately, the Persistence Ignorance principle helps make solutions related to business problems more understandable, allowing developers to concentrate more on the domain itself.

Separation of Concern
Separation of Concern (SoC) is a fundamental principle in software engineering and design that aims to divide complex systems into smaller, manageable parts. Its primary goal is to organize a system’s components so that each part focuses on a single concern or responsibility. Thus, instead of mixing multiple concerns, each component fulfills its designated function. This approach enhances the modularity, sustainability, and scalability of software systems.
In software development, SoC ensures clear separation between different areas such as business logic, data access, and user interface. For example, in the Model-View-Controller (MVC) design pattern, separating the model, view, and controller reflects this principle. Each layer handles specific responsibilities, making projects more readable, maintainable, and extendable.
Separation of Concerns is applicable not only in software development but also in various other domains. For instance, in a hospital setting, distinct roles such as doctors, nurses, and other staff contribute to more efficient organization. In software projects, this principle ensures components work independently, allowing each to focus on its own area of expertise. As a result, the overall system structure becomes more robust and comprehensible.

Keep reading, it’s always exciting to discover! 🙂

Clean Architecture Yaklaşımıyla Sürdürülebilir Yazılım Çözümleri

Sustainable Software Solutions with Clean Architecture

[TR] Dependency Inversion/Inversion Of Control Prensibi

Dependency Inversion prensibi, bağımlılıkları yönetmek için kullanılan temel ilkelerden biridir. Genellikle, bir sınıfın başka bir sınıfa bağımlılığı doğrudan kurulur; örneğin, IntertechController sınıfı, IntertechService sınıfını doğrudan kullanır. Bu durumda, IntertechService'deki public bileşenler, IntertechController tarafından doğrudan erişilebilir ve bu durum, iki sınıf arasında sıkı bir bağımlılık oluşturur. Eğer IntertechService içindeki bir metot yanlışlıkla private olarak tanımlanırsa, bu durum IntertechController'da hatalara yol açabilir. Aynı şekilde, IntertechService'in IntertechRepository'ye bağımlı olması durumunda, IntertechRepository'deki en küçük değişiklikler bile IntertechService'i etkileyebilir.

Dependency Inversion prensibi, bu sıkı bağımlılığı ortadan kaldırmak için araya bir arayüz (interface) koymayı önerir. Bu sayede, IntertechController doğrudan IntertechService'i değil, IntertechService'in arayüzünü bilmekte ve bu arayüzü implement eden sınıflarla çalışmaktadır. Bu yaklaşımın iki önemli ilkesi vardır:

1. Yüksek Seviyeli Modüller, Düşük Seviyeli Modüllere Doğrudan Bağlı Olmamalıdır. (High-level modules should not depend on low-level modules. Both should depend on abstractions.): Yüksek seviyeli modül (örneğin, IntertechController), doğrudan düşük seviyeli modülleri (örneğin, IntertechService) bilmemeli ve arada bir soyutlama olmalıdır.
2. Soyutlama Detaylar Üzerine Bağlı Olmamalıdır. (Abstractions should not depend on details. Details should depend on abstractions.): Arayüzde yer alan metodlar, uygulamanın iç detayları hakkında bilgi vermemelidir. Örneğin, GetBanks metodu, verinin nereden geldiği gibi detayları içermemelidir; bu detaylar, implementasyon sınıfında (örneğin, IntertechService) yer almalıdır.

Dependency Inversion prensibi, modüller arasındaki bağımlılıkları kırarak, uygulamaların test edilebilirliğini artırır, bakım maliyetlerini düşürür ve gelecekte yapılacak değişikliklerin sistem üzerindeki etkisini minimumda tutar. Örneğin, eğer IntertechController içinde IntertechService'e ihtiyaç duyuluyorsa ve doğrudan new ile örneklendirilmişse, IntertechService'in yerine farklı bir sınıf kullanmak istendiğinde, IntertechController'da değişiklik yapmak gerekecektir. Ancak arada bir arayüz varsa, IntertechController sadece IntertechService arayüzünü kullanmakta, dolayısıyla arayüzü implement eden sınıf değiştirildiğinde, IntertechController'ın etkilenmemesi sağlanabilir.

Dependency Inversion ve Inversion of Control (IoC) farklı kavramlardır. Dependency Inversion, yüksek seviyeli modüllerin düşük seviyeli modüllere doğrudan bağımlı olmaması gerektiğini savunur; bu bağımlılıkların bir arayüz aracılığıyla yönetilmesini sağlar. Inversion of Control ise, bir nesnenin bağımlılıklarının ve yaşam döngüsünün dış bir kontrol mekanizması tarafından yönetilmesi anlamına gelir. IoC, genellikle Dependency Injection ile uygulanarak, esneklik ve test edilebilirliği artırır.

Inversion of Control (IoC) Prensibi

Bir A sınıfının B sınıfına ihtiyaç duyduğunda B sınıfını doğrudan new ile oluşturmasını engeller; bunun yerine B sınıfı, dışarıdan constructor, method veya property injection ile sağlanır. Bu bağlamda, B sınıfına olan bağımlılığa "dependency object" denirken, A sınıfı "dependent object" olarak adlandırılır. A sınıfı, işlevini yerine getirebilmek için B sınıfına ihtiyaç duyar, ancak B sınıfını doğrudan yaratmamalıdır. Bu prensipler, en çok kullanılan tasarım desenlerinden biri olan Dependency Injection (DI) ile uygulanır. DI framework’leri, bu prensipleri kolayca uygulamamıza yardımcı olur. Örneğin, Autofac ve Ninject gibi kütüphaneler, bağımlılıkları yönetirken kodlarımızı kullanmamızı sağlayarak bir framework işlevi görür. Bir kütüphaneyi framework olarak adlandıran temel unsur, projenize eklediğinizde, kütüphanenin sizin kodlarınızı kullanıyor olmasıdır.

Framework ve Library Temel Fark

Framework, bir kütüphanenin projenize entegre edildiğinde, sizin kodlarınızı kullanıyorsa oluşur. Yani, eklediğiniz kütüphane, uygulama kodunuz üzerinde kontrol sağlıyorsa bir framework olarak adlandırılır; aksi takdirde basit bir kütüphane (library) olur.

Paketlerin bir araya gelmesi kısmen doğru olsa da, asıl belirleyici nokta, eklediğiniz paketlerin kodlarınızı nasıl kullandığıdır. Inversion of Control (IoC) ve Dependency Injection (DI) framework’leri bu anlamda önemlidir. Autofac ve Ninject gibi DI framework’leri bağımlılık yönetimini kolaylaştırır. Bu yapıların anlaşılması, yazılım geliştirmede etkinlik ve sürdürülebilirlik için kritiktir.

Kütüphane: Siz çağırırsınız, kontrol sizdedir.

Framework: Sizi çağırır, kontrol framework’tedir.

Single Responsibility Principle (SRP)

Yazılım tasarımında bir bileşenin (class, modül, mikroservis vb.) yalnızca tek bir sorumluluğa sahip olması gerektiğini belirtir. Bu ilkenin temel amacı, her bileşenin yalnızca bir işi olması ve o işi en iyi şekilde yerine getirmesidir. Örneğin, bir sınıfın hem e-posta hem de faks gönderme işlevini üstlenmesi, SRP’ye aykırıdır.

Resmi tanımına göre, bir bileşenin değişmesi için yalnızca bir nedeni olmalıdır. Bu, yazılımın bakımını ve genişletilmesini kolaylaştırır, çünkü bir bileşenin değiştirilmesi gerektiğinde, yalnızca ilgili sorumlulukların gözden geçirilmesi yeterlidir. SRP’nin uygulanması, kodun okunabilirliğini artırır ve test edilebilirliği kolaylaştırır; bu da yazılımın daha sürdürülebilir ve esnek olmasına katkıda bulunur.

Sonuç olarak, SRP, yazılım geliştirme sürecinde karmaşıklığı azaltmak ve yönetilebilirliği artırmak için kritik bir ilkedir.

Persistence Ignorance

Yazılım uygulamalarındaki domain modellerinin, özellikle entity’lerin ve iş mantığının veritabanı süreçleri ile ilgili hiçbir bilgiye sahip olmaması gerektiğini savunur. Bu prensip, entity’lerin herhangi bir ORM (Object-Relational Mapping) teknolojisiyle veya örneğin Entity Framework Core ile ilgili detaylar taşımamasını öngörür. Dolayısıyla, entity’ler dış dünyada hangi veritabanı teknolojisinin kullanıldığını bilmezler.

Persistence Ignorance, domain nesnelerinin tasarımının, iş problemini çözmek için gereken ideal yapı ile uyumlu olmasını sağlarken, kalıcılık süreçlerinin bu tasarımı kirletmemesini de temin eder. Böylece, entity’ler ve iş mantığı veritabanı detaylarıyla karışmadan, yalnızca iş kurallarını içerebilir. Bu yaklaşım, uygulamanın daha sürdürülebilir, test edilebilir ve modüler bir yapı kazanmasını sağlar. Sonuç olarak, Persistence Ignorance prensibi, iş problemleriyle ilgili çözümlerin daha anlaşılır olmasına ve geliştiricilerin iş alanına daha fazla odaklanmasına yardımcı olur.

Separation Of Concern

Yazılım mühendisliği ve tasarımında karmaşık sistemlerin daha küçük, yönetilebilir parçalara ayrılmasını amaçlayan temel bir ilkedir. Bu ilkenin temel amacı, bir sistemin bileşenlerini her bir parça tek bir konuya (concern) odaklanacak şekilde organize etmektir. Böylece, birden fazla konunun karıştırılması yerine her bileşen kendi işlevselliğini yerine getirir. Bu yaklaşım, yazılım sistemlerinin modülerliğini, sürdürülebilirliğini ve ölçeklenebilirliğini artırır.

Yazılım geliştirme bağlamında SoC, iş mantığı, veri erişimi ve kullanıcı arayüzü gibi farklı alanların net bir şekilde ayrılmasını sağlar. Örneğin, MVC (Model-View-Controller) tasarım kalıbında, model, görünüm ve kontrolcülerin ayrı ayrı ele alınması bu prensipten kaynaklanır. Her bir katman, belirli bir sorumluluk taşır ve bu sayede projeler daha okunaklı, bakımı kolay ve genişletilebilir hale gelir.

Separation of Concerns, sadece yazılım geliştirmede değil, birçok farklı alanda geçerli bir ilkedir. Örneğin, bir hastanede doktorlar, hemşireler ve diğer personelin ayrı ayrı roller üstlenmesi, karmaşık bir organizasyonu daha verimli hale getirir. Bu ilke, yazılım projelerinde bileşenlerin birbirinden bağımsız olarak çalışmasını sağlarken, aynı zamanda her bir bileşenin yalnızca kendi alanına odaklanmasına imkan tanır. Bu sayede, sistemin genel yapısı daha sağlam ve anlaşılır bir hale gelir.

Okumaya devam edin, keşfetmek her zaman heyecan vericidir! 🙂

• Autofac: Home
• Ninject
• The Unit Of Work Pattern And Persistence Ignorance
• Separation of Concerns (SoC) - GeeksforGeeks
• Building Software with Clean Architecture
• Dependency injection in ASP.NET Core

Sustainable Software Solutions with Clean Architecture was originally published in Intertech on Medium, where people are continuing the conversation by highlighting and responding to this story.

If you’d like to read the content in Turkish, please scroll down. (İçeriği Türkçe olarak okumak isterseniz lütfen aşağı kaydırın.)

[ENG] Difference Between override and new Keywords in C#

Object-oriented programming in C# is based on concepts such as inheritance and polymorphism. In inheritance, the keywords override and new are used to replace or hide methods from the base class in derived classes. Both keywords allow a method in a base class to be redefined in a derived class, but they differ in one important way.

What is override?

override allows a derived class to override a method in the base class. In this case, the overridden method in the derived class is executed, even if it is called by reference to the base class. For example:

public class Shape
{
    public virtual void Draw() => Console.WriteLine("Drawing a shape");
}

public class Circle : Shape
{
    public override void Draw() => Console.WriteLine("Drawing a circle");
}

Shape shape = new Circle();
shape.Draw(); // Output: Drawing a circle

In this code, the Draw method of the Circle class works even if the Shape reference is used. This indicates that polymorphism is provided when the override is used.

What is new?

The new keyword hides, but does not override, a method in the base class. In this case, the method of the base class is executed when the base class reference is used:

public class Rectangle : Shape
{
    public new void Draw() => Console.WriteLine("Drawing a rectangle");
}

Shape shape = new Rectangle();
shape.Draw(); // Output: Drawing a shape

Here, even though the Draw method is redefined in the Rectangle class, the Draw method in the base class is executed when called with a reference to Shape. This shows that no polymorphism is achieved with new, only the base class method is hidden.

Differences in Brief

• override: Provides polymorphism; a derived class method is valid even if called with a base class reference.
• new: Hides the method; the base class method is executed when called with a base class reference.

As a result, you should use override if you want the base class method to work with a derived class reference, and new if you just want to hide it.

Differences between class and record in C#

The record type, introduced with C# 9.0, is a type that focuses on managing data more easily and securely. Understanding the basic features that distinguish class and record structures is important to use the right type in the right situations.

What is class?

Class is the most widely used type in object oriented programming and acts as a reference type. Objects defined with class are stored in heap memory and accessed through their references in memory. Class is preferred especially in cases that require complex structures, behaviours and state management. Also, classes can contain methods, fields and various other members in addition to properties.

public class Person
{
    public string Name { get; set; }
    public int Age { get; set; }
}

What is record?

Record is a C# feature developed to make it easier to create immutable data types and acts as a reference type. records provide value equality by default, meaning that two record instances are considered equal if they have the same property values. This makes the record type particularly useful in data transport objects, data transfer and modelling situations.

public record Person(string Name, int Age);

In this example, we have defined properties directly in record and made them immutable. The properties of the Person instance cannot be changed; ‘with-expressions’ is used to create a new Person instance.

var person = new Person("Alice", 30);
var updatedPerson = person with { Age = 31 };

Differences between class and record

• The main differences between record and class types are evident in their intended use and behaviour. record types are considered immutable by default; that is, their properties cannot be changed after creation. This property ensures that data can be safely transported and used without modification. In contrast, class types are mutable, meaning that their properties can be modified, making them more flexible.
• There is also an important difference between the two types in terms of equality. record types use value equality; that is, if the property values of two record instances are the same, the two objects are considered equal. In contrast, class types use reference equality, meaning that two class objects are not considered equal unless they point to the same address in memory.
• As for their intended use, record types are ideal for moving data and processing it without modification. Structures often called ‘Data Transfer Object (DTO)’ or ‘model’ are defined with this type. On the other hand, class types are suitable for representing objects with more complex behaviour and business logic. These differences become very important in determining the right use case.

When to use class and When to use record?

• Data Modelling and Transfer: It makes more sense to use record only if you are doing data transfer and modelling. For example, record is ideal for receiving data from the API.
• Business Logic and State Management: If you are working with mutable objects that contain behavioural properties and business logic, it is more appropriate to use class.

Keep reading, it’s always exciting to discover! 🙂

[TR] C#’ta override ve new Anahtar Sözcükleri Arasındaki Fark

C# dilinde nesne yönelimli programlama, kalıtım ve çok biçimlilik gibi kavramlar üzerine kuruludur. Kalıtımda temel sınıftaki metotları türetilmiş sınıflarda değiştirmek veya gizlemek için override ve new anahtar sözcükleri kullanılır. Her iki anahtar sözcük de temel sınıftaki bir metodu türetilmiş sınıfta yeniden tanımlamaya olanak sağlar, ancak birbirlerinden önemli bir farkla ayrılırlar.

override Nedir?

override, türetilmiş sınıfın temel sınıfta bulunan bir metodu geçersiz kılmasını sağlar. Bu durumda, temel sınıf referansı ile bile çağrılsa, türetilmiş sınıftaki override edilen metot çalıştırılır. Örneğin:

public class Shape
{
    public virtual void Draw() => Console.WriteLine("Drawing a shape");
}

public class Circle : Shape
{
    public override void Draw() => Console.WriteLine("Drawing a circle");
}

Shape shape = new Circle();
shape.Draw(); // Output: Drawing a circle

Bu kodda, Shape referansı kullanılsa bile Circle sınıfının Draw metodu çalışır. Bu, override kullanıldığında çok biçimliliğin sağlandığını gösterir.

new Nedir?

new anahtar sözcüğü, temel sınıftaki bir metodu gizler, ancak geçersiz kılmaz. Bu durumda, temel sınıf referansı kullanıldığında temel sınıfın metodu çalıştırılır:

public class Rectangle : Shape
{
    public new void Draw() => Console.WriteLine("Drawing a rectangle");
}

Shape shape = new Rectangle();
shape.Draw(); // Output: Drawing a shape

Burada Draw metodu Rectangle sınıfında yeniden tanımlanmış olsa da, Shape referansı ile çağrıldığında temel sınıftaki Draw metodu çalışır. Bu, new ile çok biçimliliğin sağlanmadığını, sadece temel sınıf metodunun gizlendiğini gösterir.

Kısaca Farklar

• override: Çok biçimlilik sağlar; türetilmiş sınıf metodu temel sınıf referansı ile çağrılsa bile geçerli olur.
• new: Metodu gizler; temel sınıf referansı ile çağrıldığında temel sınıfın metodu çalışır.

Sonuç olarak, temel sınıftaki metodun türetilmiş sınıf referansı ile çalışmasını istiyorsanız override, sadece gizlemek istiyorsanız new kullanmalısınız.

C#’ta class ve record Arasındaki Farklar

C# 9.0 ile birlikte tanıtılan record türleri, veriyi daha kolay ve güvenli bir şekilde yönetmeye odaklanan bir türdür. class ve record yapılarını birbirinden ayıran temel özellikleri anlamak, doğru durumlarda doğru türü kullanmak için önemlidir.

class Nedir?

class, nesne yönelimli programlamada en yaygın kullanılan türdür ve referans tipi olarak davranır. class ile tanımlanan nesneler heap hafızada saklanır ve bellekte referansları üzerinden erişilir. Özellikle karmaşık yapılar, davranışlar ve durum yönetimi gerektiren durumlarda class tercih edilir. Ayrıca, class’lar içinde özelliklerin yanında yöntemler (methods), alanlar (fields) ve çeşitli diğer üyeler barındırabilir.

public class Person
{
    public string Name { get; set; }
    public int Age { get; set; }
}

record Nedir?

record, immutable (değişmez) veri türleri oluşturmayı kolaylaştırmak için geliştirilen bir C# özelliğidir ve referans tipi olarak davranır. record’lar varsayılan olarak value equality sağlar, yani iki record örneği aynı özellik değerlerine sahipse eşit kabul edilir. Bu, record türünü özellikle veri taşıma nesneleri, veri transferi ve modelleme durumlarında kullanışlı hale getirir.

public record Person(string Name, int Age);

Bu örnekte, record içinde özellikleri doğrudan tanımladık ve immutable olmaları sağlandı. Person örneğinin özellikleri değiştirilemez; yeni bir Person örneği oluşturmak için "with-expressions" kullanılır.

var person = new Person("Alice", 30);
var updatedPerson = person with { Age = 31 };

Class ve Record Arasındaki Farklar

1. record ve class türleri arasındaki temel farklar, kullanım amaçları ve davranışları açısından belirgindir. record türleri varsayılan olarak immutable kabul edilir; yani oluşturulduktan sonra özellikleri değiştirilemez. Bu özellik, verilerin güvenli bir şekilde taşınmasını ve değiştirilmeden kullanılmasını sağlar. Buna karşılık, class türleri mutable’dır, yani özellikleri üzerinde değişiklik yapılabilir ve bu da onları daha esnek kılar.
2. Eşitlik açısından da iki tür arasında önemli bir farklılık bulunur. record türleri value equality kullanır; yani iki record örneğinin özellik değerleri aynıysa, bu iki nesne eşit kabul edilir. Buna karşın, class türleri referans eşitliği esas alır; yani bellekte aynı adresi işaret etmedikçe iki class nesnesi eşit sayılmaz.
3. Kullanım amaçlarına gelince, record türleri veri taşımak ve değişiklik yapılmadan işlemek için idealdir. Genellikle "Data Transfer Object (DTO)" ya da "model" olarak adlandırılan yapılar bu türle tanımlanır. Öte yandan, class türleri daha karmaşık davranışları ve iş mantığını içeren nesneleri temsil etmek için uygundur. Bu farklar, doğru kullanım senaryosunu belirlemek açısından oldukça önemli hale gelir.

Ne Zaman class ve Ne Zaman record Kullanmalı?

• Veri Modelleme ve Transferi: Sadece veri taşıma ve modelleme yapıyorsanız record kullanımı daha mantıklıdır. Örneğin, API’den gelen veriyi almak için record idealdir.
• İş Mantığı ve Durum Yönetimi: Davranışsal özellikler ve iş mantığı içeren, değişebilir (mutable) nesnelerle çalışıyorsanız class kullanmak daha uygundur.

Okumaya devam edin, keşfetmek her zaman heyecan vericidir! 🙂

• C# Difference between Record and class - Microsoft Q&A
• Difference between class and record type in C#
• Knowing When to Use Override and New Keywords - C#
• Virtual vs Override vs New Keywords in C#
• C# Record vs Class: Key Differences and Best Use Cases

Structural and Behavioural Differences of C#: Class, Record, Override and New was originally published in Intertech on Medium, where people are continuing the conversation by highlighting and responding to this story.