https://www.alekseialeinikov.com/en 2026-09-08 weekly 1.0 https://www.alekseialeinikov.com/de 2026-09-08 weekly 1.0 https://www.alekseialeinikov.com/en/offer 2026-09-08 monthly 0.9 https://www.alekseialeinikov.com/de/offer 2026-09-08 monthly 0.9 https://www.alekseialeinikov.com/en/highlights 2026-09-08 monthly 0.8 https://www.alekseialeinikov.com/de/highlights 2026-09-08 monthly 0.8 https://www.alekseialeinikov.com/en/hire-me 2026-09-08 monthly 0.8 https://www.alekseialeinikov.com/de/hire-me 2026-09-08 monthly 0.8 https://www.alekseialeinikov.com/en/portfolio https://www.alekseialeinikov.com/architecture/cloud-armor-waf-k8s.webp Cloud Armor WAF for Kubernetes (GKE) Layer-7 protection for GKE via External HTTP(S) Load Balancer: OWASP WAF rules, rate limiting and geo/IP allow-deny, with Cloud Logging and Terraform IaC. https://www.alekseialeinikov.com/architecture/gke-multi-region-fleet.webp Multi-Region GKE Cluster with GitOps & Fleet Highly available GKE across multiple regions, managed with Google Fleet. Config Sync from Git keeps deployments consistent with multi-region failover. https://www.alekseialeinikov.com/architecture/cross-regional-ilb-gke.webp Cross-Regional Internal Load Balancer for GKE Round-robin load balancing across GKE clusters in different regions via Cross-Regional ILB. NEG-based, highly available, low-latency internal access. https://www.alekseialeinikov.com/architecture/backup-restore-architecture.webp Backup and Restore Multi-region backups with S3 Cross-Region Replication, Aurora Global Database and EBS snapshots — data integrity, HA and DR for critical workloads. https://www.alekseialeinikov.com/architecture/pilot-light-architecture.webp Pilot Light Architecture Pilot-light DR with Aurora Global Database, ELB and Auto Scaling Groups. Critical DBs stay on; the app tier spins up on failover for lower cost and RTO. https://www.alekseialeinikov.com/architecture/cicd-ml-architecture.webp CI/CD for ML with Vertex AI Pipelines Cloud Build and Vertex AI Pipelines automate images, artifacts and pipeline deploys from every Git commit — a full, reproducible MLOps loop. https://www.alekseialeinikov.com/architecture/warm-standby-architecture.webp Warm Standby Architecture Warm-standby environment in a secondary region with Aurora Global Database, ELB and Auto Scaling Groups for fast failover and reduced recovery time. https://www.alekseialeinikov.com/architecture/cloud-vpn-architecture.webp Cloud VPN Hub-and-Spoke Scalable hub-and-spoke on Google Cloud VPN that overcomes VPC Peering limits and enables transitive connectivity across many spoke networks. https://www.alekseialeinikov.com/architecture/hub-spoke-architecture-vpc-peering.webp VPC Peering Hub-and-Spoke Secure inter-VPC communication via Network Peering on the Google backbone, with Cloud NAT for egress and optional VPN for forwarded routes. https://www.alekseialeinikov.com/architecture/enterprise-app-oracle-database-compute-engine.webp Enterprise App on Compute Engine (Oracle DB) Regional managed instance groups behind a load balancer with Oracle Data Guard HA — Cloud NAT, Hyperdisk and Cloud Storage for performance and backups. https://www.alekseialeinikov.com/architecture/aws-multi-account-landing-zone.webp AWS Multi-Account Landing Zone Governance at scale with AWS Organizations and Control Tower: Security, Infrastructure and Workloads OUs, SCP guardrails and centralized CloudTrail/Config. https://www.alekseialeinikov.com/architecture/aws-event-driven-serverless.webp Event-Driven Serverless on EventBridge Decoupled serverless flow: API Gateway and Lambda publish to EventBridge, which routes by rule to SQS, Step Functions and DynamoDB — with DLQ safety nets. https://www.alekseialeinikov.com/architecture/aws-zero-trust-privatelink.webp Zero-Trust Private Connectivity (PrivateLink + TGW) Segmented hub-and-spoke on AWS Transit Gateway with PrivateLink endpoints to S3, KMS and Secrets Manager — east-west traffic never touches the public internet. https://www.alekseialeinikov.com/architecture/azure-enterprise-scale-landing-zone.webp Azure Enterprise-Scale Landing Zone Cloud Adoption Framework landing zone: management-group hierarchy, Azure Policy guardrails, hub-and-spoke networking with Firewall and Bastion, and Entra ID. https://www.alekseialeinikov.com/architecture/azure-aks-secure-cicd.webp Secure CI/CD for AKS (GitHub Actions + Key Vault) GitHub Actions builds, scans and signs images into ACR, then deploys to a private AKS cluster. Pods pull secrets from Key Vault via Workload Identity. https://www.alekseialeinikov.com/architecture/gcp-secure-landing-zone.webp GCP Secure Landing Zone / Org Blueprint Organization blueprint with folder hierarchy, VPC Service Controls perimeter, Org Policies, Shared VPC and centralized logging with Security Command Center. https://www.alekseialeinikov.com/architecture/gcp-rag-vertex-ai.webp Enterprise RAG on Vertex AI Retrieval-augmented generation: documents embedded in Vertex AI Vector Search; Cloud Run retrieves context and calls Gemini for grounded, cited answers. https://www.alekseialeinikov.com/architecture/gcp-bigquery-lakehouse.webp BigQuery Lakehouse Data Platform Streaming and batch ingestion via Pub/Sub and Dataflow into a BigQuery lakehouse, ELT with Dataform and unified governance with Dataplex — analytics-ready. https://www.alekseialeinikov.com/architecture/gcp-anthos-service-mesh.webp Anthos Multi-Cluster Service Mesh Hybrid fleet of GKE and on-prem clusters under Anthos: Multi-Cluster Ingress, Anthos Service Mesh with mTLS everywhere and GitOps config sync. https://www.alekseialeinikov.com/architecture/gcp-global-web-app-cdn.webp Global Web App — Cloud CDN + Cloud Armor Global HTTP(S) Load Balancer with Anycast IP fronts serverless backends: Cloud CDN caches at the edge and Cloud Armor blocks WAF and DDoS threats. https://www.alekseialeinikov.com/architecture/gcp-hybrid-interconnect-ncc.webp Hybrid Connectivity — Interconnect + NCC High-bandwidth Dedicated Interconnect with encrypted HA VPN failover and Cloud Router BGP, unified through Network Connectivity Center transitive routing. https://www.alekseialeinikov.com/architecture/gcp-eventarc-cloud-run.webp Event-Driven Serverless on Eventarc Eventarc routes CloudEvents from 90+ sources through Pub/Sub to autoscaling Cloud Run services, with dead-letter topics for at-least-once safety. https://www.alekseialeinikov.com/architecture/gcp-secure-supply-chain.webp Secure Software Supply Chain Cloud Build scans, SBOM-tracks and signs images into Artifact Registry; Binary Authorization gates unverified images before Cloud Deploy progressive rollouts. https://www.alekseialeinikov.com/architecture/gcp-zero-trust-iap.webp Zero-Trust Access with IAP / BeyondCorp Identity-Aware Proxy authorizes every request by identity and device context via Access Context Manager — no VPN and no network perimeter to trust. https://www.alekseialeinikov.com/architecture/gcp-spanner-multi-region.webp Multi-Region Resilience with Cloud Spanner Active-active app tiers in two regions behind a global load balancer share one Cloud Spanner instance with synchronous replication and a 99.999% SLA. 2026-09-08 monthly 0.8 https://www.alekseialeinikov.com/de/portfolio https://www.alekseialeinikov.com/architecture/cloud-armor-waf-k8s.webp Cloud Armor WAF für Kubernetes (GKE) Layer-7-Schutz vor GKE über External HTTP(S) Load Balancer: OWASP-WAF-Regeln, Rate Limiting und Geo/IP-Allow-Deny, mit Cloud Logging und Terraform-IaC. https://www.alekseialeinikov.com/architecture/gke-multi-region-fleet.webp Multi-Region-GKE-Cluster mit GitOps & Fleet Hochverfügbares GKE über mehrere Regionen, verwaltet mit Google Fleet. Config Sync aus Git hält Deployments konsistent — mit Multi-Region-Failover. https://www.alekseialeinikov.com/architecture/cross-regional-ilb-gke.webp Cross-Regional Internal Load Balancer für GKE Round-Robin-Lastverteilung über GKE-Cluster in verschiedenen Regionen mit Cross-Regional-ILB. NEG-basiert, hochverfügbar, geringe interne Latenz. https://www.alekseialeinikov.com/architecture/backup-restore-architecture.webp Backup und Restore Multi-Region-Backups mit S3 Cross-Region Replication, Aurora Global Database und EBS-Snapshots — Datenintegrität, HA und DR für kritische Workloads. https://www.alekseialeinikov.com/architecture/pilot-light-architecture.webp Pilot-Light-Architektur Pilot-Light-DR mit Aurora Global Database, ELB und Auto Scaling Groups. Kritische DBs bleiben aktiv; die App-Ebene startet beim Failover — geringere Kosten und RTO. https://www.alekseialeinikov.com/architecture/cicd-ml-architecture.webp CI/CD für ML mit Vertex AI Pipelines Cloud Build und Vertex AI Pipelines automatisieren Images, Artefakte und Pipeline-Deployments aus jedem Git-Commit — ein vollständiger MLOps-Kreislauf. https://www.alekseialeinikov.com/architecture/warm-standby-architecture.webp Warm-Standby-Architektur Warm-Standby-Umgebung in einer Zweitregion mit Aurora Global Database, ELB und Auto Scaling Groups — schnelles Failover und kürzere Wiederherstellungszeit. https://www.alekseialeinikov.com/architecture/cloud-vpn-architecture.webp Cloud VPN Hub-and-Spoke Skalierbares Hub-and-Spoke mit Google Cloud VPN, das VPC-Peering-Grenzen überwindet und transitive Konnektivität über viele Spoke-Netze ermöglicht. https://www.alekseialeinikov.com/architecture/hub-spoke-architecture-vpc-peering.webp VPC-Peering Hub-and-Spoke Sichere Inter-VPC-Kommunikation via Network Peering über das Google-Backbone, mit Cloud NAT für Egress und optional VPN für weitergeleitete Routen. https://www.alekseialeinikov.com/architecture/enterprise-app-oracle-database-compute-engine.webp Enterprise-App auf Compute Engine (Oracle DB) Regionale Managed Instance Groups hinter einem Load Balancer mit Oracle Data Guard HA — Cloud NAT, Hyperdisk und Cloud Storage für Performance und Backups. https://www.alekseialeinikov.com/architecture/aws-multi-account-landing-zone.webp AWS Multi-Account Landing Zone Governance at Scale mit AWS Organizations und Control Tower: Security-, Infrastructure- und Workloads-OUs, SCP-Guardrails und zentrales CloudTrail/Config. https://www.alekseialeinikov.com/architecture/aws-event-driven-serverless.webp Event-Driven Serverless mit EventBridge Entkoppelter Serverless-Flow: API Gateway und Lambda publizieren an EventBridge, das per Regel an SQS, Step Functions und DynamoDB routet — mit DLQ-Sicherheitsnetzen. https://www.alekseialeinikov.com/architecture/aws-zero-trust-privatelink.webp Zero-Trust Private Connectivity (PrivateLink + TGW) Segmentiertes Hub-and-Spoke über AWS Transit Gateway mit PrivateLink-Endpoints zu S3, KMS und Secrets Manager — Ost-West-Traffic ohne öffentliches Internet. https://www.alekseialeinikov.com/architecture/azure-enterprise-scale-landing-zone.webp Azure Enterprise-Scale Landing Zone Cloud-Adoption-Framework-Landing-Zone: Management-Group-Hierarchie, Azure-Policy-Guardrails, Hub-and-Spoke mit Firewall und Bastion sowie Entra ID. https://www.alekseialeinikov.com/architecture/azure-aks-secure-cicd.webp Sichere CI/CD für AKS (GitHub Actions + Key Vault) GitHub Actions baut, scannt und signiert Images in ACR und deployt in einen privaten AKS-Cluster. Pods beziehen Secrets aus Key Vault via Workload Identity. https://www.alekseialeinikov.com/architecture/gcp-secure-landing-zone.webp GCP Secure Landing Zone / Org-Blueprint Organisations-Blueprint mit Ordnerhierarchie, VPC-Service-Controls-Perimeter, Org Policies, Shared VPC und zentralem Logging mit Security Command Center. https://www.alekseialeinikov.com/architecture/gcp-rag-vertex-ai.webp Enterprise-RAG auf Vertex AI Retrieval-Augmented Generation: Dokumente in Vertex AI Vector Search eingebettet; Cloud Run holt Kontext und ruft Gemini für fundierte, zitierte Antworten. https://www.alekseialeinikov.com/architecture/gcp-bigquery-lakehouse.webp BigQuery-Lakehouse-Datenplattform Streaming- und Batch-Ingestion über Pub/Sub und Dataflow in ein BigQuery-Lakehouse, ELT mit Dataform und Governance mit Dataplex — analysebereit. https://www.alekseialeinikov.com/architecture/gcp-anthos-service-mesh.webp Anthos Multi-Cluster Service Mesh Hybride Flotte aus GKE- und On-Prem-Clustern unter Anthos: Multi-Cluster-Ingress, Anthos Service Mesh mit mTLS überall und GitOps-Config-Sync. https://www.alekseialeinikov.com/architecture/gcp-global-web-app-cdn.webp Globale Web-App — Cloud CDN + Cloud Armor Globaler HTTP(S)-Load-Balancer mit Anycast-IP vor Serverless-Backends: Cloud CDN cacht am Edge und Cloud Armor blockt WAF- und DDoS-Bedrohungen. https://www.alekseialeinikov.com/architecture/gcp-hybrid-interconnect-ncc.webp Hybride Konnektivität — Interconnect + NCC Hochbandbreitiger Dedicated Interconnect mit verschlüsseltem HA-VPN-Failover und Cloud-Router-BGP, vereint über transitives Routing im Network Connectivity Center. https://www.alekseialeinikov.com/architecture/gcp-eventarc-cloud-run.webp Event-Driven Serverless mit Eventarc Eventarc routet CloudEvents aus über 90 Quellen via Pub/Sub an autoskalierende Cloud-Run-Dienste, mit Dead-Letter-Topics für At-least-once-Sicherheit. https://www.alekseialeinikov.com/architecture/gcp-secure-supply-chain.webp Sichere Software-Lieferkette Cloud Build scannt, erstellt SBOMs und signiert Images in Artifact Registry; Binary Authorization sperrt unverifizierte Images vor Cloud-Deploy-Rollouts. https://www.alekseialeinikov.com/architecture/gcp-zero-trust-iap.webp Zero-Trust-Zugriff mit IAP / BeyondCorp Identity-Aware Proxy autorisiert jede Anfrage nach Identität und Gerätekontext via Access Context Manager — ohne VPN und ohne vertrautes Netzwerk-Perimeter. https://www.alekseialeinikov.com/architecture/gcp-spanner-multi-region.webp Multi-Region-Resilienz mit Cloud Spanner Active-Active-App-Ebenen in zwei Regionen hinter einem globalen Load Balancer teilen sich eine Cloud-Spanner-Instanz mit synchroner Replikation und 99,999% SLA. 2026-09-08 monthly 0.8 https://www.alekseialeinikov.com/en/contact 2026-09-08 yearly 0.7 https://www.alekseialeinikov.com/de/contact 2026-09-08 yearly 0.7 https://www.alekseialeinikov.com/en/tools 2026-08-07 monthly 0.8 https://www.alekseialeinikov.com/de/tools 2026-08-07 monthly 0.8 https://www.alekseialeinikov.com/en/tools/compute-selector 2026-08-07 monthly 0.8 https://www.alekseialeinikov.com/de/tools/compute-selector 2026-08-07 monthly 0.8 https://www.alekseialeinikov.com/en/tools/database-selector 2026-08-07 monthly 0.8 https://www.alekseialeinikov.com/de/tools/database-selector 2026-08-07 monthly 0.8 https://www.alekseialeinikov.com/en/tools/iam-checker 2026-08-07 monthly 0.8 https://www.alekseialeinikov.com/de/tools/iam-checker 2026-08-07 monthly 0.8 https://www.alekseialeinikov.com/en/cv 2026-09-08 monthly 0.6 https://www.alekseialeinikov.com/de/cv 2026-09-08 monthly 0.6 https://www.alekseialeinikov.com/en/cv/devsecops-engineer 2026-09-08 monthly 0.9 https://www.alekseialeinikov.com/de/cv/devsecops-engineer 2026-09-08 monthly 0.9 https://www.alekseialeinikov.com/en/cv/gcp-platform-engineer 2026-09-08 monthly 0.9 https://www.alekseialeinikov.com/de/cv/gcp-platform-engineer 2026-09-08 monthly 0.9 https://www.alekseialeinikov.com/en/cv/cloud-security-architect 2026-09-08 monthly 0.9 https://www.alekseialeinikov.com/de/cv/cloud-security-architect 2026-09-08 monthly 0.9 https://www.alekseialeinikov.com/en/cv/ai-engineer 2026-09-08 monthly 0.9 https://www.alekseialeinikov.com/de/cv/ai-engineer 2026-09-08 monthly 0.9 https://www.alekseialeinikov.com/en/blog 2026-09-18 weekly 0.8 https://www.alekseialeinikov.com/de/blog 2026-09-18 weekly 0.8 https://www.alekseialeinikov.com/en/blog/2 2026-09-18 weekly 0.8 https://www.alekseialeinikov.com/de/blog/2 2026-09-18 weekly 0.8 https://www.alekseialeinikov.com/en/blog/3 2026-09-18 weekly 0.8 https://www.alekseialeinikov.com/de/blog/3 2026-09-18 weekly 0.8 https://www.alekseialeinikov.com/en/blog/4 2026-09-18 weekly 0.8 https://www.alekseialeinikov.com/de/blog/4 2026-09-18 weekly 0.8 https://www.alekseialeinikov.com/en/blog/5 2026-09-18 weekly 0.8 https://www.alekseialeinikov.com/de/blog/5 2026-09-18 weekly 0.8 https://www.alekseialeinikov.com/en/blog/6 2026-09-18 weekly 0.8 https://www.alekseialeinikov.com/de/blog/6 2026-09-18 weekly 0.8 https://www.alekseialeinikov.com/en/blog/topics/ai/ai-coding-agents-2026-claude-code-vs-codex-vs-opencode https://www.alekseialeinikov.com/blog/ai-coding-agents-2026.webp AI Coding Agents in 2026: Claude Code vs Codex vs opencode https://www.alekseialeinikov.com/blog/ai-coding-agents-loop-2026.webp The agent loop: your prompt goes to the model, which plans a step, calls tools to read/edit files and run commands, observes the result, and repeats until the task is done and it shows you a diff. https://www.alekseialeinikov.com/blog/ai-coding-agents-positioning-2026.webp Positioning matrix on two axes — closed vs open source, and locked to one vendor vs any model. Claude Code and Codex sit together in the closed, vendor-locked corner and both also run local and in a managed cloud; opencode sits alone in the open, any-model corner. https://www.alekseialeinikov.com/blog/ai-coding-agents-governance-2026.webp Four guardrails: permission prompts before edits and commands, sandboxed execution in a container or VM, scoped tool/MCP access with deny-by-default, and a human reviewing the diff before it merges. 2026-07-14 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/ai/ki-coding-agents-2026-claude-code-vs-codex-vs-opencode https://www.alekseialeinikov.com/blog/ai-coding-agents-2026.webp KI-Coding-Agents 2026: Claude Code vs Codex vs opencode https://www.alekseialeinikov.com/blog/ai-coding-agents-loop-2026.webp Die Agent-Schleife: Dein Prompt geht ans Modell, das einen Schritt plant, Tools zum Lesen/Ändern von Dateien und Ausführen von Befehlen aufruft, das Ergebnis beobachtet und wiederholt, bis die Aufgabe erledigt ist und es dir einen Diff zeigt. https://www.alekseialeinikov.com/blog/ai-coding-agents-positioning-2026.webp Positionierungsmatrix auf zwei Achsen — closed vs Open Source und an einen Anbieter gebunden vs beliebiges Modell. Claude Code und Codex sitzen zusammen in der closed, anbietergebundenen Ecke und laufen beide lokal und in einer verwalteten Cloud; opencode sitzt allein in der offenen Ecke mit beliebigem Modell. https://www.alekseialeinikov.com/blog/ai-coding-agents-governance-2026.webp Vier Leitplanken: Berechtigungsabfragen vor Änderungen und Befehlen, Sandbox-Ausführung in Container oder VM, eingegrenzter Tool-/MCP-Zugriff mit Deny-by-default, und ein Mensch, der den Diff vor dem Merge prüft. 2026-07-14 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/ai/browser-ai-webgpu-litert-js-2026 https://www.alekseialeinikov.com/blog/litert-js-browser-ai-2026.webp Browser AI in 2026: Running Models On-Device with WebGPU and LiteRT.js https://www.alekseialeinikov.com/blog/litert-js-server-vs-ondevice-2026.webp Server inference versus on-device inference in the browser with LiteRT.js. https://www.alekseialeinikov.com/blog/litert-js-inference-stack-2026.webp LiteRT.js inference stack: your web app calls the runtime, which dispatches to CPU, GPU, or NPU backends. 2026-07-10 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/ai/ki-im-browser-webgpu-litert-js-2026 https://www.alekseialeinikov.com/blog/litert-js-browser-ai-2026.webp KI im Browser 2026: Modelle mit WebGPU und LiteRT.js on-device ausführen https://www.alekseialeinikov.com/blog/litert-js-server-vs-ondevice-2026.webp Server-Inferenz gegenüber On-Device-Inferenz im Browser mit LiteRT.js. https://www.alekseialeinikov.com/blog/litert-js-inference-stack-2026.webp LiteRT.js-Inferenz-Stack: deine Web-App ruft das Runtime auf, das an CPU-, GPU- oder NPU-Backends verteilt. 2026-07-10 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/ai/claude-fable-mythos-pricing-cache-read-rule https://www.alekseialeinikov.com/blog/claude-fable-mythos-cache-pricing.webp Claude Fable and Mythos Cost Twice as Much as Opus. For Agents, They Can Cost Less https://www.alekseialeinikov.com/blog/claude-fable-mythos-price-inversion.webp Base input and cache read move in opposite directions: Claude Fable costs twice as much per input token as Opus 5 but half as much per cached token. https://www.alekseialeinikov.com/blog/claude-fable-mythos-crossover.webp Cost per agent turn against output size for a 200K cached prefix: the Fable and Opus 5 lines cross at 2,000 output tokens. 2026-09-04 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/ai/claude-fable-mythos-preise-cache-read-regel https://www.alekseialeinikov.com/blog/claude-fable-mythos-cache-pricing.webp Claude Fable und Mythos kosten doppelt so viel wie Opus. Für Agenten können sie günstiger sein https://www.alekseialeinikov.com/blog/claude-fable-mythos-price-inversion.webp Basis-Input und Cache-Read bewegen sich gegenläufig: Claude Fable kostet pro Input-Token doppelt so viel wie Opus 5, pro gecachtem Token aber nur die Hälfte. https://www.alekseialeinikov.com/blog/claude-fable-mythos-crossover.webp Kosten pro Agentenzug über die Output-Größe bei 200K gecachtem Prefix: Die Kurven von Fable und Opus 5 kreuzen sich bei 2.000 Output-Token. 2026-09-04 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/ai/context-engineering-2026-what-replaced-prompt-engineering https://www.alekseialeinikov.com/blog/context-engineering-2026.webp Context Engineering in 2026: What Replaced Prompt Engineering https://www.alekseialeinikov.com/blog/context-engineering-rot-2026.webp Recall degrades as the context window fills — a performance gradient, not a cliff. https://www.alekseialeinikov.com/blog/context-engineering-anatomy-2026.webp The anatomy of a context window: system prompt, tools, examples, retrieved data and history, each competing for a finite attention budget. https://www.alekseialeinikov.com/blog/context-engineering-strategies-2026.webp Compaction, note-taking and sub-agents compared: what each is best for and what it costs. 2026-08-07 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/ai/context-engineering-2026-was-prompt-engineering-abgeloest-hat https://www.alekseialeinikov.com/blog/context-engineering-2026.webp Context Engineering 2026: Was Prompt Engineering abgelöst hat https://www.alekseialeinikov.com/blog/context-engineering-rot-2026.webp Die Erinnerungsfähigkeit sinkt, je voller das Kontextfenster wird — ein Leistungsgefälle, keine harte Kante. https://www.alekseialeinikov.com/blog/context-engineering-anatomy-2026.webp Die Anatomie eines Kontextfensters: System-Prompt, Tools, Beispiele, abgerufene Daten und Historie konkurrieren um ein endliches Attention-Budget. https://www.alekseialeinikov.com/blog/context-engineering-strategies-2026.webp Compaction, Notizen und Sub-Agenten im Vergleich: wofür sich jede Technik eignet und was sie kostet. 2026-08-07 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/ai/real-time-rag-pipeline-python-bright-data-serp-api-2026 https://www.alekseialeinikov.com/blog/1_AZXu0egNKmqClH60smyc8g.webp Real-Time RAG in Python: Feed Your LLM Live Google Results (2026) https://www.alekseialeinikov.com/blog/1_Wohoz87yXzB3cSCD2bhRug.webp Selecting Bright Data's SERP API before connecting it to a Python retrieval workflow https://www.alekseialeinikov.com/blog/1_RRzhMba3r3_s_VOiO8pfFg.webp Configuring a Bright Data SERP API for a Python demo, with Light JSON selected to return the top organic search results https://www.alekseialeinikov.com/blog/1_B9Y-u0P07Vl1DzQQ8fhtkg.webp Top organic search results returned by Bright Data's SERP API in a simple Python script https://www.alekseialeinikov.com/blog/1_o99ORrWGOm2R2MV2TEKtWQ.webp Transforming fresh search results into a lightweight RAG context block 2026-06-27 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/ai/echtzeit-rag-pipeline-python-bright-data-serp-api-2026 https://www.alekseialeinikov.com/blog/1_AZXu0egNKmqClH60smyc8g.webp Echtzeit-RAG in Python: Live-Google-Ergebnisse für dein LLM (2026) https://www.alekseialeinikov.com/blog/1_Wohoz87yXzB3cSCD2bhRug.webp Bright Datas SERP API auswählen, bevor sie mit einem Python-Retrieval-Workflow verbunden wird https://www.alekseialeinikov.com/blog/1_RRzhMba3r3_s_VOiO8pfFg.webp Eine Bright-Data-SERP-API für eine Python-Demo konfigurieren, mit Light JSON ausgewählt für die Top-organischen Suchergebnisse https://www.alekseialeinikov.com/blog/1_B9Y-u0P07Vl1DzQQ8fhtkg.webp Top organische Suchergebnisse von Bright Datas SERP API in einem einfachen Python-Skript zurückgegeben https://www.alekseialeinikov.com/blog/1_o99ORrWGOm2R2MV2TEKtWQ.webp Frische Suchergebnisse in einen leichtgewichtigen RAG-Kontextblock transformieren 2026-06-27 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/ai/genai-vs-agentic-ai-vs-ai-agents-vs-llm-2026 https://www.alekseialeinikov.com/blog/genai-agentic-ai-agents-llm-2026.webp GenAI vs Agentic AI vs AI Agents vs LLM: What's the Actual Difference? https://www.alekseialeinikov.com/blog/ai-terms-nesting-2026.webp A nested diagram of three concentric rounded boxes. The innermost box is the LLM (the model). It sits inside a larger box, the AI agent (LLM plus tools plus a loop). That sits inside the outermost box, agentic AI (multiple agents orchestrated). To the side, a separate badge shows GenAI as the umbrella category the LLM belongs to, spanning text, image, audio and video. https://www.alekseialeinikov.com/blog/ai-terms-request-flow-2026.webp A horizontal flow showing the same request, "Book a flight under 500 dollars", handled at three levels. The LLM returns text instructions only. The AI agent runs a reason-act-observe loop, calling a flight search tool and a booking tool. The agentic system has an orchestrator delegating to a flight agent, a calendar agent and a budget agent, then combining their results. https://www.alekseialeinikov.com/blog/ai-terms-decision-2026.webp A decision tree titled "What do you actually need?". First question: do you just need to generate or reason over content? If yes, use an LLM (or GenAI more broadly). Next: does it need to take actions or call tools? If yes, use an AI agent. Next: do multiple specialized agents need to coordinate on a complex workflow? If yes, use agentic AI. A warning box at the bottom reads: most production agents are just an LLM plus a prompt — don't over-engineer. 2026-07-21 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/ai/genai-vs-agentic-ai-vs-ki-agenten-vs-llm-2026 https://www.alekseialeinikov.com/blog/genai-agentic-ai-agents-llm-2026.webp GenAI vs. Agentic AI vs. KI-Agenten vs. LLM: Was ist der echte Unterschied? https://www.alekseialeinikov.com/blog/ai-terms-nesting-2026.webp Ein verschachteltes Diagramm aus drei konzentrischen abgerundeten Boxen. Die innerste Box ist das LLM (das Modell). Es sitzt in einer größeren Box, dem KI-Agenten (LLM plus Tools plus Schleife). Diese sitzt in der äußersten Box, Agentic AI (mehrere orchestrierte Agenten). Daneben zeigt ein separates Abzeichen GenAI als Oberkategorie, zu der das LLM gehört, über Text, Bild, Audio und Video. https://www.alekseialeinikov.com/blog/ai-terms-request-flow-2026.webp Ein horizontaler Ablauf, der dieselbe Anfrage „Buch einen Flug unter 500 Euro" auf drei Ebenen zeigt. Das LLM gibt nur Textanweisungen zurück. Der KI-Agent führt eine denken-handeln-beobachten-Schleife aus und ruft ein Flugsuche-Tool und ein Buchungs-Tool auf. Das agentische System hat einen Orchestrator, der an einen Flug-Agenten, einen Kalender-Agenten und einen Budget-Agenten delegiert und dann deren Ergebnisse kombiniert. https://www.alekseialeinikov.com/blog/ai-terms-decision-2026.webp Ein Entscheidungsbaum mit dem Titel „Was brauchst du wirklich?". Erste Frage: Musst du nur Inhalte erzeugen oder über sie nachdenken? Wenn ja, nutze ein LLM (oder GenAI im weiteren Sinne). Weiter: Muss es handeln oder Tools aufrufen? Wenn ja, nutze einen KI-Agenten. Weiter: Müssen mehrere spezialisierte Agenten einen komplexen Workflow koordinieren? Wenn ja, nutze Agentic AI. Eine Warnbox unten sagt: Die meisten Agenten in Produktion sind nur ein LLM plus Prompt — nicht überkonstruieren. 2026-07-21 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/ai/machines-checking-machines-ai-detection-absurdity-2026 https://www.alekseialeinikov.com/blog/ai-detection-absurdity-2026.webp Machines Checking Machines: The Great AI-Detection Absurdity of 2026 https://www.alekseialeinikov.com/blog/ai-detection-loop-2026.webp A circular ouroboros-style loop diagram. An AI writes text, an AI detector flags it as AI, a paid AI 'humanizer' rewrites the text to evade detection, the detector is updated to catch humanized text, and the arrow returns to the start — an endless loop with no ground truth in the middle, labelled 'no human, no truth'. https://www.alekseialeinikov.com/blog/ai-detection-human-out-of-loop-2026.webp A left-to-right pipeline showing a résumé passing through three machines with no human. AI writes the résumé, an AI applicant tracking system reads and ranks it, and an AI detector judges whether it was AI-written. A crossed-out human icon sits below with the label 'nobody evaluated the actual work'. A small callout shows a candidate hiding white-text instructions in the résumé to manipulate the AI screener. https://www.alekseialeinikov.com/blog/ai-detection-measure-instead-2026.webp A simple two-column contrast. The left column, 'stop measuring: authorship', shows a broken detector asking 'was AI used?' with an X. The right column, 'start measuring: outcome', lists the real questions — is the writing true and useful, is the code correct and secure, can the person do the work — plus 'provenance and disclosure where it matters'. A caption reads 'judge the work, not the tool'. 2026-07-25 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/ai/maschinen-die-maschinen-pruefen-ki-erkennung-absurditaet-2026 https://www.alekseialeinikov.com/blog/ai-detection-absurdity-2026.webp Maschinen, die Maschinen prüfen: Die große KI-Erkennungs-Absurdität von 2026 https://www.alekseialeinikov.com/blog/ai-detection-loop-2026.webp Ein kreisförmiges Ouroboros-artiges Schleifendiagramm. Eine KI schreibt Text, ein KI-Detektor flaggt ihn als KI, ein bezahlter KI-'Humanizer' schreibt den Text um, um der Erkennung zu entgehen, der Detektor wird aktualisiert, um humanisierten Text zu fangen, und der Pfeil kehrt zum Start zurück — eine endlose Schleife ohne Grundwahrheit in der Mitte, beschriftet mit 'kein Mensch, keine Wahrheit'. https://www.alekseialeinikov.com/blog/ai-detection-human-out-of-loop-2026.webp Eine Pipeline von links nach rechts, die einen Lebenslauf durch drei Maschinen ohne Menschen zeigt. KI schreibt den Lebenslauf, ein KI-Bewerbermanagementsystem liest und rankt ihn, und ein KI-Detektor urteilt, ob er KI-geschrieben war. Ein durchgestrichenes Menschen-Symbol steht darunter mit der Beschriftung 'niemand hat die eigentliche Arbeit bewertet'. Ein kleiner Hinweis zeigt einen Kandidaten, der Anweisungen in weißem Text im Lebenslauf versteckt, um den KI-Screener zu manipulieren. https://www.alekseialeinikov.com/blog/ai-detection-measure-instead-2026.webp Ein einfacher Zwei-Spalten-Kontrast. Die linke Spalte, 'nicht mehr messen: Autorschaft', zeigt einen kaputten Detektor, der fragt 'wurde KI genutzt?' mit einem X. Die rechte Spalte, 'anfangen zu messen: Ergebnis', listet die echten Fragen — ist der Text wahr und nützlich, ist der Code korrekt und sicher, kann die Person die Arbeit — plus 'Herkunft und Offenlegung, wo es zählt'. Eine Bildunterschrift lautet 'beurteile die Arbeit, nicht das Werkzeug'. 2026-07-25 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/ai/mcp-servers-explained-build-and-run-safely-2026 https://www.alekseialeinikov.com/blog/mcp-servers-2026.webp MCP Servers Explained: Build One, Then Run It Safely https://www.alekseialeinikov.com/blog/mcp-n-times-m-2026.webp Without a protocol every app needs custom code for every system (N×M); with MCP each side implements once (N+M). https://www.alekseialeinikov.com/blog/mcp-primitives-2026.webp The three server primitives differ by who initiates them: model-invoked tools, application-controlled resources, user-invoked prompts. https://www.alekseialeinikov.com/blog/mcp-security-2026.webp Safe tool invocation: deny-by-default allow-list, argument validation, scoped identity, confirmation for destructive actions, full audit log. 2026-08-03 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/ai/mcp-server-erklaert-selbst-bauen-und-sicher-betreiben-2026 https://www.alekseialeinikov.com/blog/mcp-servers-2026.webp MCP-Server erklärt: selbst bauen und sicher betreiben https://www.alekseialeinikov.com/blog/mcp-n-times-m-2026.webp Ohne Protokoll braucht jede App eigenen Code für jedes System (N×M); mit MCP implementiert jede Seite einmal (N+M). https://www.alekseialeinikov.com/blog/mcp-primitives-2026.webp Die drei Primitive unterscheiden sich darin, wer sie auslöst: vom Modell aufgerufene Tools, von der Anwendung gesteuerte Resources, vom Nutzer aufgerufene Prompts. https://www.alekseialeinikov.com/blog/mcp-security-2026.webp Sicherer Tool-Aufruf: Deny-by-default-Allowlist, Argumentprüfung, gescopte Identität, Bestätigung für destruktive Aktionen, vollständiges Audit-Log. 2026-08-03 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/ai/quantization-explained-run-70b-model-consumer-hardware-2026 https://www.alekseialeinikov.com/blog/quantization-2026.webp Quantization Explained: How to Run a 70B Model on Consumer Hardware https://www.alekseialeinikov.com/blog/quantization-formats-2026.webp GGUF splits across CPU and GPU; AWQ and GPTQ are GPU-first; bitsandbytes enables QLoRA fine-tuning. https://www.alekseialeinikov.com/blog/quantization-levels-2026.webp Quality versus memory across quantization levels: the curve barely moves from 16 to 4 bits, then falls sharply below Q4. https://www.alekseialeinikov.com/blog/quantization-vram-2026.webp Total memory is weights plus KV cache plus overhead — the KV cache grows with context length. 2026-08-05 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/ai/quantisierung-erklaert-70b-modell-auf-normaler-hardware-2026 https://www.alekseialeinikov.com/blog/quantization-2026.webp Quantisierung erklärt: Wie man ein 70B-Modell auf normaler Hardware betreibt https://www.alekseialeinikov.com/blog/quantization-formats-2026.webp GGUF verteilt auf CPU und GPU; AWQ und GPTQ sind GPU-orientiert; bitsandbytes ermöglicht QLoRA-Finetuning. https://www.alekseialeinikov.com/blog/quantization-levels-2026.webp Qualität gegen Speicher über die Quantisierungsstufen: Von 16 auf 4 Bit bewegt sich die Kurve kaum, unter Q4 fällt sie steil ab. https://www.alekseialeinikov.com/blog/quantization-vram-2026.webp Der Gesamtspeicher besteht aus Gewichten, KV-Cache und Overhead — der KV-Cache wächst mit der Kontextlänge. 2026-08-05 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/ai/vllm-vs-ollama-inference-server-2026 https://www.alekseialeinikov.com/blog/vllm-vs-ollama-2026.webp vLLM vs Ollama: Which Inference Server You Actually Need in 2026 https://www.alekseialeinikov.com/blog/vllm-ollama-flow-2026.webp Diagram of how Ollama serves a request: ollama run pulls a GGUF model once, llama.cpp runs the inference on CPU or GPU offload, and returns one streamed response with no request queue or multi-tenant scheduler https://www.alekseialeinikov.com/blog/vllm-continuous-batching-2026.webp Diagram of vLLM continuous batching: two GPU slots run Request A then Request D back-to-back, and Request B then C then E, with a new request filling a freed slot the instant the previous one finishes rather than waiting for the whole batch https://www.alekseialeinikov.com/blog/vllm-ollama-decision-2026.webp Decision matrix for choosing between Ollama and vLLM across five scenarios: prototyping, internal tools, customer-facing APIs, multi-GPU fleets, and edge devices 2026-09-15 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/ai/vllm-vs-ollama-inference-server-2026-vergleich https://www.alekseialeinikov.com/blog/vllm-vs-ollama-2026.webp vLLM vs. Ollama: Welchen Inference-Server Sie 2026 wirklich brauchen https://www.alekseialeinikov.com/blog/vllm-ollama-flow-2026.webp Diagramm, wie Ollama eine Anfrage bedient: ollama run zieht einmalig ein GGUF-Modell, llama.cpp führt die Inferenz auf CPU oder mit GPU-Offload aus und liefert eine gestreamte Antwort ohne Warteschlange oder Multi-Tenant-Scheduler https://www.alekseialeinikov.com/blog/vllm-continuous-batching-2026.webp Diagramm des Continuous Batching von vLLM: Zwei GPU-Slots verarbeiten Anfrage A und danach Anfrage D direkt hintereinander, sowie Anfrage B, dann C, dann E, wobei eine neue Anfrage einen frei gewordenen Slot sofort füllt, statt auf den gesamten Batch zu warten https://www.alekseialeinikov.com/blog/vllm-ollama-decision-2026.webp Entscheidungsmatrix für die Wahl zwischen Ollama und vLLM über fünf Szenarien: Prototyping, interne Tools, kundenseitige APIs, Multi-GPU-Flotten und Edge-Geräte 2026-09-15 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/ai/which-embedding-model-api-vs-self-hosted-2026 https://www.alekseialeinikov.com/blog/embedding-model-2026.webp Which Embedding Model Should You Use? API vs Self-Hosted in 2026 https://www.alekseialeinikov.com/blog/embedding-dimensions-cost-2026.webp Vector width sets storage cost: 384 dimensions is 1.5 GB per million vectors, 3,072 is 12.3 GB, and pgvector's approximate indexes stop at 2,000 dimensions. https://www.alekseialeinikov.com/blog/embedding-where-it-runs-2026.webp Where an embedding model runs: hosted API, self-hosted GPU for bulk indexing, or self-hosted CPU with ONNX or OpenVINO int8 for query-time embedding. 2026-09-01 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/ai/welches-embedding-modell-api-vs-self-hosted-2026 https://www.alekseialeinikov.com/blog/embedding-model-2026.webp Welches Embedding-Modell? API oder Self-Hosted im Jahr 2026 https://www.alekseialeinikov.com/blog/embedding-dimensions-cost-2026.webp Die Vektorbreite bestimmt die Speicherkosten: 384 Dimensionen sind 1,5 GB pro Million Vektoren, 3.072 sind 12,3 GB, und die Näherungsindizes von pgvector enden bei 2.000 Dimensionen. https://www.alekseialeinikov.com/blog/embedding-where-it-runs-2026.webp Wo ein Embedding-Modell läuft: gehostete API, selbst gehostete GPU für die Massenindexierung oder selbst gehostete CPU mit ONNX oder OpenVINO in int8 für das Embedding zur Abfragezeit. 2026-09-01 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/architecture/cap-theorem-2026-what-it-really-means-for-choosing-a-database https://www.alekseialeinikov.com/blog/cap-theorem-2026.webp The CAP Theorem, Honestly: What It Really Means When You Pick a Database https://www.alekseialeinikov.com/blog/cap-partition-2026.webp During a partition, one side must choose: block to stay correct (CP), or answer with stale data to stay available (AP). https://www.alekseialeinikov.com/blog/cap-database-map-2026.webp A rough map: CP stores block to stay correct, AP stores answer to stay available, and PACELC adds the everyday latency axis. 2026-07-28 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/architecture/cap-theorem-2026-was-es-wirklich-fuer-die-datenbankwahl-bedeutet https://www.alekseialeinikov.com/blog/cap-theorem-2026.webp Das CAP-Theorem, ehrlich erklärt: Was es wirklich für die Datenbankwahl bedeutet https://www.alekseialeinikov.com/blog/cap-partition-2026.webp Während einer Partition muss eine Seite wählen: blockieren, um korrekt zu bleiben (CP), oder mit veralteten Daten antworten, um verfügbar zu bleiben (AP). https://www.alekseialeinikov.com/blog/cap-database-map-2026.webp Eine grobe Karte: CP-Stores blockieren, um korrekt zu bleiben, AP-Stores antworten, um verfügbar zu bleiben, und PACELC ergänzt die alltägliche Latenzachse. 2026-07-28 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/architecture/domain-driven-design-2026-a-practical-guide https://www.alekseialeinikov.com/blog/domain-driven-design-2026.webp Domain-Driven Design in 2026: A Practical Guide https://www.alekseialeinikov.com/blog/ddd-bounded-context-2026.webp The same term modelled differently inside three bounded contexts, each with its own ubiquitous language, connected by explicit translation. https://www.alekseialeinikov.com/blog/ddd-context-map-2026.webp A context map: core, supporting, and generic subdomains connected by customer-supplier and anticorruption-layer relationships. https://www.alekseialeinikov.com/blog/ddd-aggregate-2026.webp Aggregate anatomy: a root entity guarding invariants over its value objects, referencing another aggregate by ID and emitting a domain event. 2026-08-01 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/architecture/domain-driven-design-2026-ein-praktischer-leitfaden https://www.alekseialeinikov.com/blog/domain-driven-design-2026.webp Domain-Driven Design 2026: Ein praktischer Leitfaden https://www.alekseialeinikov.com/blog/ddd-bounded-context-2026.webp Derselbe Begriff, in drei Bounded Contexts unterschiedlich modelliert, jeder mit eigener Ubiquitous Language, verbunden durch explizite Übersetzung. https://www.alekseialeinikov.com/blog/ddd-context-map-2026.webp Eine Context Map: Kern-, unterstützende und generische Subdomänen, verbunden durch Customer-Supplier- und Anticorruption-Layer-Beziehungen. https://www.alekseialeinikov.com/blog/ddd-aggregate-2026.webp Anatomie eines Aggregats: eine Wurzel-Entity, die Invarianten über ihre Value Objects wahrt, ein anderes Aggregat per ID referenziert und ein Domain Event auslöst. 2026-08-01 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/architecture/send-one-million-notifications-without-falling-over-2026 https://www.alekseialeinikov.com/blog/million-notifications-2026.webp How to Send 1,000,000 Notifications Without Falling Over https://www.alekseialeinikov.com/blog/million-notifications-problem-2026.webp Sending inside the request blocks the thread and floods on a spike; enqueue-and-return keeps the API fast while workers drain the queue. https://www.alekseialeinikov.com/blog/million-notifications-fanout-2026.webp One producer publishes to an ingress topic; a fan-out step splits work into isolated push, email, and SMS queues, each with its own workers and provider. https://www.alekseialeinikov.com/blog/million-notifications-reliability-2026.webp Four guards keep it up: retry with backoff, a dead-letter queue, idempotency keys, and per-provider back-pressure. 2026-07-13 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/architecture/eine-million-benachrichtigungen-versenden-ohne-abzustuerzen-2026 https://www.alekseialeinikov.com/blog/million-notifications-2026.webp Wie man 1.000.000 Benachrichtigungen versendet, ohne abzustürzen https://www.alekseialeinikov.com/blog/million-notifications-problem-2026.webp Der Versand im Request blockiert den Thread und flutet bei einer Spitze; Annehmen-und-Antworten hält die API schnell, während Worker die Queue abbauen. https://www.alekseialeinikov.com/blog/million-notifications-fanout-2026.webp Ein Producer publiziert in ein Ingress-Topic; ein Fan-out-Schritt teilt die Arbeit in isolierte Push-, E-Mail- und SMS-Queues mit je eigenen Workern und Providern. https://www.alekseialeinikov.com/blog/million-notifications-reliability-2026.webp Vier Schutzmechanismen halten es oben: Retry mit Backoff, eine Dead-Letter-Queue, Idempotenz-Schlüssel und Back-Pressure pro Provider. 2026-07-13 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/architecture/idempotency-in-practice-api-retries-2026 https://www.alekseialeinikov.com/blog/idempotency-2026.webp Idempotency in Practice: Why Your Retry Just Charged the Customer Twice https://www.alekseialeinikov.com/blog/idempotency-states-2026.webp The lifecycle of an idempotency key: absent, in flight, and complete are three different states. https://www.alekseialeinikov.com/blog/idempotency-race-2026.webp Same key arriving twice: the first claims it atomically, the second is told to come back. 2026-08-14 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/architecture/idempotenz-in-der-praxis-api-retries-2026 https://www.alekseialeinikov.com/blog/idempotency-2026.webp Idempotenz in der Praxis: Warum Ihr Retry gerade doppelt abgebucht hat https://www.alekseialeinikov.com/blog/idempotency-states-2026.webp Der Lebenszyklus eines Idempotency-Keys: abwesend, in Bearbeitung und abgeschlossen sind drei verschiedene Zustände. https://www.alekseialeinikov.com/blog/idempotency-race-2026.webp Derselbe Key trifft zweimal ein: Der erste beansprucht ihn atomar, der zweite wird vertröstet. 2026-08-14 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/architecture/monolith-vs-microservices-2026-honest-trade-offs https://www.alekseialeinikov.com/blog/monolith-microservices-2026.webp Monolith vs Microservices in 2026: The Honest Trade-offs https://www.alekseialeinikov.com/blog/monolith-microservices-structure-2026.webp Side by side: a monolith's in-process modules and shared database versus independent services with their own data and a network between them. https://www.alekseialeinikov.com/blog/monolith-microservices-tradeoff-2026.webp Complexity moves, it doesn't vanish: a monolith carries more code coupling, microservices carry more operational and distributed complexity. https://www.alekseialeinikov.com/blog/monolith-microservices-decision-2026.webp A decision guide: team size, domain clarity, scaling needs and ops maturity point toward monolith, modular monolith, or microservices. 2026-07-31 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/architecture/monolith-vs-microservices-2026-ehrliche-abwaegung https://www.alekseialeinikov.com/blog/monolith-microservices-2026.webp Monolith vs. Microservices 2026: Die ehrliche Abwägung https://www.alekseialeinikov.com/blog/monolith-microservices-structure-2026.webp Nebeneinander: die In-Process-Module und geteilte Datenbank eines Monolithen versus unabhängige Services mit eigenen Daten und einem Netzwerk dazwischen. https://www.alekseialeinikov.com/blog/monolith-microservices-tradeoff-2026.webp Komplexität verschiebt sich, sie verschwindet nicht: ein Monolith trägt mehr Code-Kopplung, Microservices tragen mehr operative und verteilte Komplexität. https://www.alekseialeinikov.com/blog/monolith-microservices-decision-2026.webp Ein Entscheidungsleitfaden: Teamgröße, Domänenklarheit, Skalierungsbedarf und Betriebsreife weisen zu Monolith, modularem Monolith oder Microservices. 2026-07-31 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/architecture/pubsub-vs-eventarc-2026-event-driven-gcp-without-spaghetti https://www.alekseialeinikov.com/blog/pubsub-eventarc-2026.webp Pub/Sub or Eventarc? Event-Driven GCP Without the Spaghetti https://www.alekseialeinikov.com/blog/pubsub-eventarc-flow-2026.webp Event-driven GCP at a glance: Google emits to Eventarc, you publish to Pub/Sub, fan out to idempotent subscribers, dead-letter the poison. 2026-06-29 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/architecture/pubsub-oder-eventarc-2026-event-driven-gcp-ohne-spaghetti https://www.alekseialeinikov.com/blog/pubsub-eventarc-2026.webp Pub/Sub oder Eventarc? Event-Driven GCP ohne Spaghetti https://www.alekseialeinikov.com/blog/pubsub-eventarc-flow-2026.webp Event-driven GCP auf einen Blick: Google sendet an Eventarc, du publizierst an Pub/Sub, Fan-out zu idempotenten Subscribern, Dead-Letter für das Gift. 2026-06-29 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/architecture/rate-limiting-in-practice-algorithms-headers-2026 https://www.alekseialeinikov.com/blog/rate-limiting-2026.webp Rate Limiting in Practice: The Algorithm Matters Less Than What You Return https://www.alekseialeinikov.com/blog/rate-limiting-window-2026.webp The fixed window boundary: two legal bursts either side of the reset add up to double the limit. https://www.alekseialeinikov.com/blog/rate-limiting-headers-2026.webp What everyone ships versus what the draft actually specifies. 2026-08-17 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/architecture/rate-limiting-in-der-praxis-algorithmen-header-2026 https://www.alekseialeinikov.com/blog/rate-limiting-2026.webp Rate Limiting in der Praxis: Der Algorithmus zählt weniger als Ihre Antwort https://www.alekseialeinikov.com/blog/rate-limiting-window-2026.webp Die Fixed-Window-Grenze: zwei legale Bursts links und rechts des Resets ergeben das doppelte Limit. https://www.alekseialeinikov.com/blog/rate-limiting-headers-2026.webp Was alle ausliefern gegen das, was der Draft tatsächlich spezifiziert. 2026-08-17 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/architecture/scalability-bottleneck-is-not-the-cpu-2026 https://www.alekseialeinikov.com/blog/scalability-bottleneck-2026.webp Scalability: The Bottleneck Is Almost Never the CPU 2026-09-11 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/architecture/skalierbarkeit-der-engpass-ist-selten-die-cpu-2026 https://www.alekseialeinikov.com/blog/scalability-bottleneck-2026.webp Skalierbarkeit: Der Engpass ist fast nie die CPU 2026-09-11 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/architecture/secure-by-default-gke-reference-architecture-2026 https://www.alekseialeinikov.com/blog/gke-secure-2026.webp Secure-by-Default GKE: A Reference Architecture for 2026 https://www.alekseialeinikov.com/blog/gke-defense-in-depth-2026.webp Six independent layers of defense in depth around a GKE workload: identity, network, supply chain, admission and policy, workload runtime, observability. https://www.alekseialeinikov.com/blog/gke-zero-trust-flow-2026.webp Zero Trust on GKE: a pod's Kubernetes service account federates to a Google identity, GCP STS issues a short-lived token, and the workload calls the API with no static key involved. https://www.alekseialeinikov.com/blog/gke-supply-chain-2026.webp Supply chain on GKE: CI builds and signs an image, Artifact Registry stores it, and Binary Authorization admits signed images while blocking unsigned ones before they reach a node. 2026-07-05 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/architecture/secure-by-default-gke-referenzarchitektur-2026 https://www.alekseialeinikov.com/blog/gke-secure-2026.webp Secure-by-Default GKE: Eine Referenzarchitektur für 2026 https://www.alekseialeinikov.com/blog/gke-defense-in-depth-2026.webp Sechs unabhängige Schichten Defense in Depth um einen GKE-Workload: Identität, Netzwerk, Supply Chain, Admission und Policy, Workload-Runtime, Observability. https://www.alekseialeinikov.com/blog/gke-zero-trust-flow-2026.webp Zero Trust auf GKE: der Kubernetes-Service-Account eines Pods föderiert zu einer Google-Identität, GCP STS stellt ein kurzlebiges Token aus, und der Workload ruft die API ohne statischen Schlüssel auf. https://www.alekseialeinikov.com/blog/gke-supply-chain-2026.webp Supply Chain auf GKE: CI baut und signiert ein Image, Artifact Registry speichert es, und Binary Authorization lässt signierte Images zu, während es unsignierte blockiert, bevor sie einen Node erreichen. 2026-07-05 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/architecture/sovereign-by-design-building-a-sovereign-platform-on-kubernetes-2026 https://www.alekseialeinikov.com/blog/sovereign-by-design-2026.webp Sovereign by Design: Building a Sovereign Platform on Kubernetes https://www.alekseialeinikov.com/blog/sovereignty-three-layers-2026.webp The three layers of sovereignty — data residency and access, operational control, and technical portability — and what keeps each one yours. https://www.alekseialeinikov.com/blog/sovereignty-kubernetes-portability-2026.webp Portability as the freedom to leave: proprietary services force a rewrite, while Kubernetes manifests redeploy unchanged across GKE, EKS, AKS or an EU-hosted cluster. https://www.alekseialeinikov.com/blog/sovereignty-key-custody-2026.webp Key custody vs the CLOUD Act: when you hold the keys in an external manager, the provider stores only ciphertext and legal reach yields nothing readable. 2026-07-12 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/architecture/sovereign-by-design-eine-souveraene-plattform-auf-kubernetes-bauen-2026 https://www.alekseialeinikov.com/blog/sovereign-by-design-2026.webp Sovereign by Design: Eine souveräne Plattform auf Kubernetes bauen https://www.alekseialeinikov.com/blog/sovereignty-three-layers-2026.webp Die drei Schichten der Souveränität — Datenresidenz und Zugriff, betriebliche Kontrolle und technische Portabilität — und was jede davon dir erhält. https://www.alekseialeinikov.com/blog/sovereignty-kubernetes-portability-2026.webp Portabilität als Freiheit zu gehen: proprietäre Dienste erzwingen ein Rewrite, während Kubernetes-Manifeste unverändert über GKE, EKS, AKS oder ein EU-gehostetes Cluster neu ausgerollt werden. https://www.alekseialeinikov.com/blog/sovereignty-key-custody-2026.webp Schlüsselhoheit vs. CLOUD Act: Hältst du die Schlüssel in einem externen Manager, speichert der Anbieter nur Ciphertext und rechtlicher Zugriff bringt nichts Lesbares. 2026-07-12 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/career/ai-certification-2026-what-each-one-proves https://www.alekseialeinikov.com/blog/ai-certification-2026.webp The AI Certification Market Split Into Four Bands. Only One Matches Your Job https://www.alekseialeinikov.com/blog/ai-certification-bands-2026.webp Four bands of AI certification in 2026: business judgement, platform building, physical infrastructure, and partner-gated exams. https://www.alekseialeinikov.com/blog/ai-certification-model-vendors-2026.webp Three access models for AI certification exams in 2026: open registration at AWS, Google, NVIDIA and Salesforce; partner-gated at Anthropic; and no exam at all at OpenAI. 2026-09-03 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/career/ki-zertifizierung-2026-was-jede-wirklich-beweist https://www.alekseialeinikov.com/blog/ai-certification-2026.webp Der Markt für KI-Zertifizierungen zerfällt in vier Bänder. Nur eines passt zu Ihrem Job https://www.alekseialeinikov.com/blog/ai-certification-bands-2026.webp Vier Bänder der KI-Zertifizierung 2026: Geschäftsurteil, Plattformbau, physische Infrastruktur und partnerexklusive Prüfungen. https://www.alekseialeinikov.com/blog/ai-certification-model-vendors-2026.webp Drei Zugangsmodelle für KI-Prüfungen 2026: offene Anmeldung bei AWS, Google, NVIDIA und Salesforce; partnerexklusiv bei Anthropic; gar keine Prüfung bei OpenAI. 2026-09-03 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/career/ai-orchestration-engineering-skill-2026 https://www.alekseialeinikov.com/blog/ai-orchestration-engineering-skill-2026.webp The Real 2026 Engineering Skill Isn't Coding — It's Orchestrating AI https://www.alekseialeinikov.com/blog/ai-orchestration-function-not-profession-2026.webp Three-panel diagram titled "AI replaces the function, not the profession". Left panel lists three exposed categories with their statistics: routine white-collar work down roughly a quarter, scripted customer service where agentic AI may resolve up to 80 percent of common issues by 2029, content on autopilot with 37 percent of companies already replacing people. A large arrow points to the right panel, which contrasts the shallow version of a job that dies against the deep version that thrives, with three engineering example rows for a backend developer, an ops engineer, and a data analyst. https://www.alekseialeinikov.com/blog/ai-orchestration-conductor-2026.webp Diagram of a human orchestrator conducting multiple AI platforms. A single figure labelled "you, the orchestrator" sits on the left with the caption "which model for which task, chain, verify, own the result". A horizontal distribution bus fans out to five AI platform nodes on the right — a coding agent, a writing model, a data-analysis model, a translation engine, and a research agent. Each returns output back to a verification gate in front of the orchestrator, emphasizing that the human directs and checks rather than produces. https://www.alekseialeinikov.com/blog/ai-orchestration-hard-currency-2026.webp Diagram titled "Five skills that became hard currency" showing five columns, each a labelled chip: Empathy — read what the other person truly feels; Presence — charisma, energy, personal contact; Ethics — a conscience AI does not have; Creativity — make the genuinely new, not remix the old; Leadership — make people follow when things are hard. Above the row a banner reads "was: soft skills → now: hard currency". Below, a two-manager example note explains that both use AI to prep, but only one senses the client is nervous and closes on trust. 2026-07-27 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/career/ki-orchestrierung-engineering-faehigkeit-2026 https://www.alekseialeinikov.com/blog/ai-orchestration-engineering-skill-2026.webp Die eigentliche Engineering-Fähigkeit 2026 ist nicht Coden — es ist KI-Orchestrierung https://www.alekseialeinikov.com/blog/ai-orchestration-function-not-profession-2026.webp Dreiteiliges Diagramm mit dem Titel „AI replaces the function, not the profession". Das linke Feld listet drei bedrohte Kategorien mit ihren Statistiken: routinemäßige Büroarbeit etwa ein Viertel weniger, skriptbasierter Kundenservice, wo agentische KI bis 2029 bis zu 80 Prozent der typischen Vorfälle lösen könnte, Content auf Autopilot mit 37 Prozent der Unternehmen, die Menschen bereits ersetzen. Ein großer Pfeil zeigt auf das rechte Feld, das die oberflächliche Version eines Jobs, die stirbt, gegen die tiefe Version, die gedeiht, stellt, mit drei Engineering-Beispielzeilen für einen Backend-Entwickler, einen Ops-Engineer und einen Datenanalysten. https://www.alekseialeinikov.com/blog/ai-orchestration-conductor-2026.webp Diagramm eines menschlichen Orchestrators, der mehrere KI-Plattformen dirigiert. Eine einzelne Figur mit der Beschriftung „you, the orchestrator" sitzt links mit der Bildunterschrift „which model for which task, chain, verify, own the result". Ein horizontaler Verteilungsbus fächert nach rechts zu fünf KI-Plattform-Knoten auf — ein Coding-Agent, ein Schreibmodell, ein Datenanalyse-Modell, eine Übersetzungs-Engine und ein Recherche-Agent. Jeder gibt Output an ein Prüf-Gate vor dem Orchestrator zurück, was betont, dass der Mensch dirigiert und prüft, statt zu produzieren. https://www.alekseialeinikov.com/blog/ai-orchestration-hard-currency-2026.webp Diagramm mit dem Titel „Five skills that became hard currency", das fünf Spalten zeigt, jede ein beschrifteter Chip: Empathy — read what the other person truly feels; Presence — charisma, energy, personal contact; Ethics — a conscience AI does not have; Creativity — make the genuinely new, not remix the old; Leadership — make people follow when things are hard. Über der Reihe steht ein Banner „was: soft skills → now: hard currency". Darunter erklärt eine Notiz mit zwei Managern, dass beide KI zur Vorbereitung nutzen, aber nur einer spürt, dass der Kunde nervös ist, und auf Vertrauen abschließt. 2026-07-27 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/career/developers-learn-cloud-2026-google-cloud-first https://www.alekseialeinikov.com/blog/developer-learn-cloud-2026.webp You Can Code. In 2026, That's Not Enough — Learn the Cloud (Google Cloud First) https://www.alekseialeinikov.com/blog/code-to-cloud-roadmap-2026.webp The roadmap from code to cloud in six steps: you can code, cloud basics, go deep in one cloud, ship cloud-native, certify, stay ahead. https://www.alekseialeinikov.com/blog/developer-cloud-skill-map-2026.webp T-shaped skill map: a broad cloud base of compute, networking, IAM, storage, containers, IaC, CI/CD, and observability, combined with the ability to own a feature end to end. https://www.alekseialeinikov.com/blog/why-google-cloud-2026.webp Why Google Cloud first: strong in data and AI, GKE as the Kubernetes gold standard, excellent developer experience — and the DACH opportunity from less competition. https://www.alekseialeinikov.com/blog/gcp-cert-path-2026.webp The GCP certification path: Cloud Digital Leader optional, Associate Cloud Engineer as the first real target, then Professional Architect and specializations. 2026-07-07 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/career/entwickler-cloud-lernen-2026-google-cloud-zuerst https://www.alekseialeinikov.com/blog/developer-learn-cloud-2026.webp Du kannst programmieren? 2026 reicht das nicht — lern die Cloud (Google Cloud zuerst) https://www.alekseialeinikov.com/blog/code-to-cloud-roadmap-2026.webp Die Roadmap vom Code zur Cloud in sechs Schritten: du kannst coden, Cloud-Grundlagen, eine Cloud in die Tiefe, cloud-native liefern, zertifizieren, vorne bleiben. https://www.alekseialeinikov.com/blog/developer-cloud-skill-map-2026.webp T-Shaped Skill-Map: eine breite Cloud-Basis aus Compute, Netzwerk, IAM, Storage, Containern, IaC, CI/CD und Observability, kombiniert mit der Fähigkeit, ein Feature end-to-end zu besitzen. https://www.alekseialeinikov.com/blog/why-google-cloud-2026.webp Warum Google Cloud zuerst: stark in Data und KI, GKE als Kubernetes-Goldstandard, hervorragende Developer Experience — und die DACH-Chance durch weniger Konkurrenz. https://www.alekseialeinikov.com/blog/gcp-cert-path-2026.webp Der GCP-Zertifizierungspfad: Cloud Digital Leader optional, Associate Cloud Engineer als erstes echtes Ziel, danach Professional Architect und Spezialisierungen. 2026-07-07 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/career/is-your-career-ai-proof-2026 https://www.alekseialeinikov.com/blog/is-your-career-ai-proof-2026.webp Is Your Career AI-Proof? What Companies Get Wrong About AI and Juniors https://www.alekseialeinikov.com/blog/ai-proof-what-ai-automates-2026.webp Horizontal bar chart titled "How much of the work AI can actually automate", showing boilerplate and CRUD near 90 percent, unit tests and glue code high, refactoring in the middle, and architecture decisions, security judgment, and incident response near the bottom at under 15 percent. https://www.alekseialeinikov.com/blog/ai-proof-tool-vs-judgment-2026.webp A two-by-two matrix. The horizontal axis is "Can produce code" from low to high; the vertical axis is "Can judge architecture" from low to high. A junior with AI sits in the bottom-right: high code output, low judgment. A senior without AI sits upper-left. A senior with AI sits top-right as the target quadrant "ships fast AND safe". The bottom-right is labelled "ships fast, breaks quietly". https://www.alekseialeinikov.com/blog/ai-proof-durable-skills-2026.webp A layered pyramid of durable skills. The wide base is "syntax and boilerplate" marked as automatable and fading; above it "framework and API knowledge" amplified by AI; then "system design and trade-offs"; then "security and reliability judgment"; and at the narrow top "deciding what to build and owning production" marked as the most AI-proof. To the right, a callout shows platform guardrails — policy-as-code, IAM, review gates, IaC — as the net that contains bad judgment whether it comes from a human or an agent. 2026-07-20 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/career/ist-deine-karriere-ki-sicher-2026 https://www.alekseialeinikov.com/blog/is-your-career-ai-proof-2026.webp Ist Deine Karriere KI-sicher? Was Unternehmen bei KI und Junioren falsch verstehen https://www.alekseialeinikov.com/blog/ai-proof-what-ai-automates-2026.webp Horizontales Balkendiagramm mit dem Titel „Wie viel der Arbeit KI wirklich automatisieren kann", das Boilerplate und CRUD nahe 90 Prozent zeigt, Unit-Tests und Glue-Code hoch, Refactoring in der Mitte, und Architekturentscheidungen, Sicherheitsurteil und Incident Response unten bei unter 15 Prozent. https://www.alekseialeinikov.com/blog/ai-proof-tool-vs-judgment-2026.webp Eine Zwei-mal-zwei-Matrix. Die horizontale Achse ist „Kann Code produzieren" von niedrig bis hoch; die vertikale Achse ist „Kann Architektur beurteilen" von niedrig bis hoch. Ein Junior mit KI sitzt unten rechts: hoher Code-Output, niedriges Urteil. Ein Senior ohne KI oben links. Ein Senior mit KI oben rechts als Zielquadrant „liefert schnell UND sicher". Unten rechts ist beschriftet „liefert schnell, bricht leise". https://www.alekseialeinikov.com/blog/ai-proof-durable-skills-2026.webp Eine geschichtete Pyramide bleibender Fähigkeiten. Die breite Basis ist „Syntax und Boilerplate", als automatisierbar und verblassend markiert; darüber „Framework- und API-Wissen", von KI verstärkt; dann „Systemdesign und Abwägungen"; dann „Sicherheits- und Zuverlässigkeitsurteil"; und an der schmalen Spitze „entscheiden, was gebaut wird, und Produktion verantworten", als am meisten KI-sicher markiert. Rechts zeigt ein Hinweis Plattform-Leitplanken — Policy-as-Code, IAM, Review-Gates, IaC — als das Netz, das schlechtes Urteil eindämmt, ob von Mensch oder Agent. 2026-07-20 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/cloud/app-engine-vs-cloud-run-2026 https://www.alekseialeinikov.com/blog/app-engine-vs-cloud-run-2026.webp App Engine vs Cloud Run: Google Picked a Side. Your Bill Might Not Agree https://www.alekseialeinikov.com/blog/app-engine-vs-cloud-run-cost-2026.webp Cost comparison: Cloud Run costs more at list price but wins through scale-to-zero and committed use discounts. https://www.alekseialeinikov.com/blog/app-engine-vs-cloud-run-migration-2026.webp Migration mapping: what ports cleanly from App Engine to Cloud Run and what has no equivalent. 2026-09-07 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/cloud/app-engine-vs-cloud-run-2026-vergleich https://www.alekseialeinikov.com/blog/app-engine-vs-cloud-run-2026.webp App Engine vs. Cloud Run: Google hat sich entschieden. Ihre Rechnung vielleicht nicht https://www.alekseialeinikov.com/blog/app-engine-vs-cloud-run-cost-2026.webp Kostenvergleich: Cloud Run ist zum Listenpreis teurer, gewinnt aber über Scale-to-Zero und Committed Use Discounts. https://www.alekseialeinikov.com/blog/app-engine-vs-cloud-run-migration-2026.webp Migrations-Mapping: Was sauber von App Engine zu Cloud Run übergeht und was kein Äquivalent hat. 2026-09-07 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/cloud/backups-are-not-disaster-recovery-2026 https://www.alekseialeinikov.com/blog/backups-vs-dr-2026.webp Backups Are Not Disaster Recovery — Here's the Difference That Will Cost You https://www.alekseialeinikov.com/blog/backups-vs-dr-scope-2026.webp Backup is a single box inside disaster recovery — which also needs infra, network, DNS, secrets and a runbook. https://www.alekseialeinikov.com/blog/rto-rpo-timeline-2026.webp RPO looks backward to the last good copy (data you lose); RTO looks forward to service restored (time you're down). https://www.alekseialeinikov.com/blog/dr-strategies-ladder-2026.webp Four DR strategies on a ladder: cost and recovery speed rise together from backup & restore to multi-site active/active. 2026-07-30 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/cloud/backups-sind-kein-disaster-recovery-2026 https://www.alekseialeinikov.com/blog/backups-vs-dr-2026.webp Backups sind kein Disaster Recovery — der Unterschied, der dich teuer zu stehen kommt https://www.alekseialeinikov.com/blog/backups-vs-dr-scope-2026.webp Backup ist eine einzelne Box innerhalb von Disaster Recovery — das auch Infrastruktur, Netzwerk, DNS, Secrets und ein Runbook braucht. https://www.alekseialeinikov.com/blog/rto-rpo-timeline-2026.webp RPO blickt zurück zur letzten guten Kopie (Daten, die du verlierst); RTO blickt nach vorn zum wiederhergestellten Dienst (Zeit, die du offline bist). https://www.alekseialeinikov.com/blog/dr-strategies-ladder-2026.webp Vier DR-Strategien auf einer Leiter: Kosten und Wiederherstellungstempo steigen zusammen von Backup & Restore bis Multi-Site Active/Active. 2026-07-30 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/cloud/cloud-cost-optimization-2026-aws-vs-gcp-vs-azure https://www.alekseialeinikov.com/blog/cloud-cost-aws-gcp-azure-2026.webp The Cloud Bill You Did Not Estimate: FinOps Across AWS, GCP and Azure https://www.alekseialeinikov.com/blog/cloud-bill-anatomy-2026.webp Two bar charts side by side: the estimated bill is a single compute block, the invoiced bill adds internet egress, NAT gateway, cross-zone traffic and a control-plane fee on top. https://www.alekseialeinikov.com/blog/cloud-cost-three-clouds-2026.webp Comparison table of AWS, Google Cloud and Azure list prices for free egress allowance, internet egress first tier, managed Kubernetes control plane, extended Kubernetes version support and NAT per-GB processing. https://www.alekseialeinikov.com/blog/cloud-cost-what-to-fix-first-2026.webp Ranked list of cost levers: put a CDN in front of egress, kill idle NAT gateways, keep chatty services in one zone, right-size before you commit, consolidate clusters — each with a relative payoff bar and an effort rating. 2026-09-16 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/cloud/cloud-kosten-optimieren-2026-aws-vs-gcp-vs-azure https://www.alekseialeinikov.com/blog/cloud-cost-aws-gcp-azure-2026.webp Die Cloud-Rechnung, die du nicht kalkuliert hast: FinOps bei AWS, GCP und Azure https://www.alekseialeinikov.com/blog/cloud-bill-anatomy-2026.webp Zwei Balken nebeneinander: die kalkulierte Rechnung ist ein einzelner Compute-Block, die tatsächliche Rechnung legt Internet-Egress, NAT-Gateway, zonenübergreifenden Traffic und eine Control-Plane-Gebühr obendrauf. https://www.alekseialeinikov.com/blog/cloud-cost-three-clouds-2026.webp Vergleichstabelle der Listenpreise von AWS, Google Cloud und Azure für Egress-Freikontingent, Internet-Egress erste Stufe, Managed-Kubernetes-Control-Plane, Extended-Support-Version und NAT-Verarbeitung pro GB. https://www.alekseialeinikov.com/blog/cloud-cost-what-to-fix-first-2026.webp Rangliste der Kostenhebel: CDN vor den Egress setzen, ungenutzte NAT-Gateways abschalten, gesprächige Dienste in eine Zone legen, richtig dimensionieren vor dem Commitment, Cluster konsolidieren — jeweils mit Balken für den relativen Nutzen und einer Aufwandsbewertung. 2026-09-16 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/cloud/cloudflare-r2-vs-s3-egress-costs-2026 https://www.alekseialeinikov.com/blog/r2-vs-s3-egress-2026.webp Cloudflare R2 vs S3: What Egress Actually Costs You (and Where R2 Bills Instead) https://www.alekseialeinikov.com/blog/r2-vs-s3-bill-anatomy-2026.webp Side-by-side anatomy of an S3 bill and an R2 bill showing storage, operations and egress components, with egress metered on S3 and free on R2 while R2 shifts the weight onto Class A and Class B operations https://www.alekseialeinikov.com/blog/r2-vs-s3-fine-print-2026.webp Five billing details that inflate object storage costs: binary gigabytes on S3, LIST billed at PUT rate, charges for bytes sent after a dropped connection, R2 rounding usage up to the next billing unit, and minimum object size and duration rules 2026-08-21 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/cloud/cloudflare-r2-vs-s3-egress-kosten-2026 https://www.alekseialeinikov.com/blog/r2-vs-s3-egress-2026.webp Cloudflare R2 vs S3: Was Egress wirklich kostet (und wo R2 stattdessen abrechnet) https://www.alekseialeinikov.com/blog/r2-vs-s3-bill-anatomy-2026.webp Anatomie einer S3- und einer R2-Rechnung im Vergleich: Speicher, Operationen und Egress, wobei Egress bei S3 bepreist und bei R2 kostenlos ist, während R2 das Gewicht auf Class-A- und Class-B-Operationen verlagert https://www.alekseialeinikov.com/blog/r2-vs-s3-fine-print-2026.webp Fünf Abrechnungsdetails, die Objektspeicher verteuern: binäre Gigabyte bei S3, LIST zum PUT-Tarif, Gebühren für Bytes nach einem Verbindungsabbruch, Aufrundung auf die nächste Abrechnungseinheit bei R2 sowie Mindestgröße und Mindestdauer 2026-08-21 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/cloud/gke-autopilot-vs-standard-2026 https://www.alekseialeinikov.com/blog/gke-autopilot-vs-standard-2026.webp GKE Autopilot vs Standard in 2026: The Real Trade-offs https://www.alekseialeinikov.com/blog/gke-architecture-2026.webp GKE architecture: both modes share a Google-managed control plane. In Autopilot, Google also owns node provisioning, OS, and kubelet. In Standard, you own and configure all of that. https://www.alekseialeinikov.com/blog/gke-cost-model-2026.webp Cost comparison: Autopilot charges per pod resource request — variable with load. Standard charges per GCE node VM — fixed regardless of utilisation. At low or bursty load Autopilot wins; at consistently high utilisation Standard wins. https://www.alekseialeinikov.com/blog/gke-decision-2026.webp Decision flowchart: does a workload need elevated node access — privileged pods, node SSH, a custom or Ubuntu node OS, or Windows nodes? → Standard. Consistently >75% node utilisation? → Standard. Otherwise → Autopilot. 2026-07-15 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/cloud/gke-autopilot-vs-standard-vergleich-2026 https://www.alekseialeinikov.com/blog/gke-autopilot-vs-standard-2026.webp GKE Autopilot vs Standard 2026: Die echten Trade-offs https://www.alekseialeinikov.com/blog/gke-architecture-2026.webp GKE-Architektur: Beide Modi teilen eine von Google verwaltete Control Plane. In Autopilot besitzt Google auch Node-Provisioning, Betriebssystem und kubelet. In Standard besitzt und konfigurierst du das alles selbst. https://www.alekseialeinikov.com/blog/gke-cost-model-2026.webp Kostenvergleich: Autopilot berechnet pro Pod-Resource-Request — variabel mit der Last. Standard berechnet pro GCE-Node-VM — fix, unabhängig von der Auslastung. Bei geringer oder variabler Last gewinnt Autopilot; bei konstant hoher Auslastung gewinnt Standard. https://www.alekseialeinikov.com/blog/gke-decision-2026.webp Entscheidungs-Flowchart: Braucht ein Workload erhöhten Node-Zugriff — privilegierte Pods, Node-SSH, ein eigenes/Ubuntu-Node-OS oder Windows-Nodes? → Standard. Konstant >75% Node-Auslastung? → Standard. Sonst → Autopilot. 2026-07-15 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/cloud/gke-gateway-api-vs-ingress-2026 https://www.alekseialeinikov.com/blog/gke-gateway-api-2026.webp GKE Gateway API vs Ingress 2026: When to Stop Using nginx https://www.alekseialeinikov.com/blog/gke-gateway-vs-ingress-2026.webp Ingress packs frontend, routing, TLS, and vendor annotations into one object; Gateway API splits the same job into GatewayClass, Gateway, and HTTPRoute, each owned by a different role. https://www.alekseialeinikov.com/blog/gke-gatewayclasses-2026.webp The four single-cluster GatewayClasses: global-external-managed (recommended), regional-external-managed and rilb (both need a proxy-only subnet), and the legacy gxlb to avoid. https://www.alekseialeinikov.com/blog/gke-gateway-decision-2026.webp Decision flow: internal traffic goes to gke-l7-rilb; external single-region to regional-external-managed; external global to global-external-managed. In every branch the data plane is Google-managed, with no nginx pods to run. 2026-07-16 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/cloud/gke-gateway-api-vs-ingress-nginx-abloesen-2026 https://www.alekseialeinikov.com/blog/gke-gateway-api-2026.webp GKE Gateway API vs Ingress 2026: Wann nginx Geschichte ist https://www.alekseialeinikov.com/blog/gke-gateway-vs-ingress-2026.webp Ingress packt Frontend, Routing, TLS und Anbieter-Annotationen in ein Objekt; Gateway API teilt dieselbe Aufgabe in GatewayClass, Gateway und HTTPRoute, jede in der Hand einer anderen Rolle. https://www.alekseialeinikov.com/blog/gke-gatewayclasses-2026.webp Die vier Single-Cluster-GatewayClasses: global-external-managed (empfohlen), regional-external-managed und rilb (beide brauchen ein Proxy-only-Subnetz) und das veraltete gxlb zum Meiden. https://www.alekseialeinikov.com/blog/gke-gateway-decision-2026.webp Entscheidungsfluss: interner Verkehr geht zu gke-l7-rilb; externer Single-Region zu regional-external-managed; externer global zu global-external-managed. In jedem Zweig ist die Datenebene Google-verwaltet, ohne nginx-Pods. 2026-07-16 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/cloud/google-adk-build-production-ai-agents-2026 https://www.alekseialeinikov.com/blog/google-adk-production-agents-2026.webp Google ADK in 2026: Building Production AI Agents with the Agent Development Kit 2026-06-27 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/cloud/google-adk-produktionsreife-ki-agenten-bauen-2026 https://www.alekseialeinikov.com/blog/google-adk-produktionsreife-agenten-2026.webp Google ADK 2026: Produktionsreife KI-Agenten mit dem Agent Development Kit bauen 2026-06-27 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/cloud/google-cloud-ambassador-infrastructure-journey-2026 https://www.alekseialeinikov.com/blog/google-cloud-ambassador-infrastructure-2026.webp I Became a Google Cloud Ambassador — Infrastructure: Here Is What It Actually Takes in 2026 2026-06-28 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/cloud/google-cloud-ambassador-infrastructure-weg-2026 https://www.alekseialeinikov.com/blog/google-cloud-ambassador-infrastructure-2026.webp Ich wurde Google Cloud Ambassador — Infrastructure: Was es in 2026 wirklich braucht 2026-06-28 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/cloud/kafka-vs-pubsub-2026-managed-messaging-fintech-outage https://www.alekseialeinikov.com/blog/1_IJ1D6OsYDPbHYYzKmJ2PyA.webp Kafka vs Pub/Sub in 2026: When Managed Messaging Saves a Fintech Launch 2026-06-28 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/cloud/kafka-vs-pubsub-2026-managed-messaging-rettet-fintech-launch https://www.alekseialeinikov.com/blog/1_IJ1D6OsYDPbHYYzKmJ2PyA.webp Kafka vs Pub/Sub 2026: Wenn Managed Messaging einen Fintech Launch rettet 2026-06-28 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/cloud/managed-kubernetes-what-eks-aks-gke-actually-manage-2026 https://www.alekseialeinikov.com/blog/managed-kubernetes-2026.webp Managed Kubernetes: The Word Is Doing a Lot of Work https://www.alekseialeinikov.com/blog/managed-kubernetes-boundary-2026.webp The responsibility boundary across four managed Kubernetes options — EKS managed node groups, EKS Auto Mode, AKS and GKE Autopilot — showing which layers the provider operates and which stay with the customer https://www.alekseialeinikov.com/blog/managed-kubernetes-node-tax-2026.webp How much of a node is actually available for workloads after kubelet and system reservations on GKE and AKS, with the documented reservation formulas for CPU and memory 2026-08-27 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/cloud/managed-kubernetes-was-eks-aks-gke-wirklich-verwalten-2026 https://www.alekseialeinikov.com/blog/managed-kubernetes-2026.webp Managed Kubernetes: Das Wort leistet ziemlich viel Arbeit https://www.alekseialeinikov.com/blog/managed-kubernetes-boundary-2026.webp Die Verantwortungsgrenze bei vier Managed-Kubernetes-Optionen — EKS Managed Node Groups, EKS Auto Mode, AKS und GKE Autopilot — mit den Schichten, die der Anbieter betreibt, und denen, die beim Kunden bleiben https://www.alekseialeinikov.com/blog/managed-kubernetes-node-tax-2026.webp Wie viel eines Nodes nach kubelet- und System-Reservierungen bei GKE und AKS tatsächlich für Workloads verfügbar bleibt, mit den dokumentierten Formeln für CPU und Memory 2026-08-27 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/cloud/what-belongs-in-a-cloud-landing-zone-2026 https://www.alekseialeinikov.com/blog/landing-zone-2026.webp What Actually Belongs in a Landing Zone — and What Gets Pushed Into One for No Reason https://www.alekseialeinikov.com/blog/landing-zone-core-2026.webp The four irreversible landing zone decisions — identity, resource hierarchy, network addressing and security boundaries — shown against the deferrable layer of monitoring, cost control, backup and DR, API management and cluster management https://www.alekseialeinikov.com/blog/landing-zone-sequence-2026.webp Landing zone sequencing: irreversible decisions before the first workload, hybrid connectivity and operational tooling deliberately deferred to run in parallel once something is already deployed 2026-08-25 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/cloud/was-gehoert-in-eine-cloud-landing-zone-2026 https://www.alekseialeinikov.com/blog/landing-zone-2026.webp Was wirklich in eine Landing Zone gehört — und was ohne Grund hineingeschoben wird https://www.alekseialeinikov.com/blog/landing-zone-core-2026.webp Die vier unumkehrbaren Landing-Zone-Entscheidungen — Identität, Ressourcenhierarchie, Netzadressierung und Sicherheitsgrenzen — gegenüber der aufschiebbaren Schicht aus Monitoring, Kostenkontrolle, Backup und DR, API- und Cluster-Management https://www.alekseialeinikov.com/blog/landing-zone-sequence-2026.webp Reihenfolge einer Landing Zone: unumkehrbare Entscheidungen vor dem ersten Workload, hybride Konnektivität und Betriebswerkzeuge bewusst nachgelagert und parallel, sobald etwas läuft 2026-08-25 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/data/bigquery-vs-snowflake-2026-honest-comparison https://www.alekseialeinikov.com/blog/bigquery-vs-snowflake-2026.webp BigQuery vs Snowflake in 2026: An Honest Comparison From a GCP Engineer https://www.alekseialeinikov.com/blog/bq-snowflake-architecture-2026.webp BigQuery is serverless; Snowflake gives you virtual warehouses you size yourself. https://www.alekseialeinikov.com/blog/bq-snowflake-pricing-2026.webp BigQuery bills on bytes scanned; Snowflake bills on warehouse size times runtime. https://www.alekseialeinikov.com/blog/bq-snowflake-decision-2026.webp A decision guide: pick BigQuery vs pick Snowflake, by scenario. 2026-07-07 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/data/bigquery-vs-snowflake-2026-ehrlicher-vergleich https://www.alekseialeinikov.com/blog/bigquery-vs-snowflake-2026.webp BigQuery vs Snowflake 2026: Ein ehrlicher Vergleich von einem GCP-Engineer https://www.alekseialeinikov.com/blog/bq-snowflake-architecture-2026.webp BigQuery ist serverless; Snowflake gibt dir Virtual Warehouses, die du selbst dimensionierst. https://www.alekseialeinikov.com/blog/bq-snowflake-pricing-2026.webp BigQuery rechnet nach gescannten Bytes ab; Snowflake nach Warehouse-Groesse mal Laufzeit. https://www.alekseialeinikov.com/blog/bq-snowflake-decision-2026.webp Entscheidungshilfe: BigQuery waehlen vs Snowflake waehlen, je nach Szenario. 2026-07-07 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/data/do-you-need-a-graph-database-2026 https://www.alekseialeinikov.com/blog/graph-database-2026.webp Do You Need a Graph Database? What BigQuery Graph Going GA Actually Changes https://www.alekseialeinikov.com/blog/graph-vs-sql-traversal-2026.webp Variable-length traversal is the dividing line: SQL needs one self-join per hop and the depth must be known when you write the query, while GQL expresses the same question with a quantifier. https://www.alekseialeinikov.com/blog/bigquery-graph-architecture-2026.webp BigQuery Graph sits over existing tables with no ETL, but running GQL requires an Enterprise or Enterprise Plus reservation; on-demand pricing only gets the GRAPH_EXPAND function. https://www.alekseialeinikov.com/blog/graph-analytics-vs-operational-2026.webp Two graph products, one language: Spanner Graph answers neighbourhood questions in milliseconds while BigQuery Graph answers whole-graph questions in seconds to hours, with data moving both ways. 2026-09-02 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/data/brauchst-du-eine-graphdatenbank-2026 https://www.alekseialeinikov.com/blog/graph-database-2026.webp Brauchst du eine Graphdatenbank? Was die GA von BigQuery Graph wirklich ändert https://www.alekseialeinikov.com/blog/graph-vs-sql-traversal-2026.webp Traversierung variabler Länge ist die Trennlinie: SQL braucht einen Self-Join pro Sprung und die Tiefe muss beim Schreiben feststehen, während GQL dieselbe Frage mit einem Quantor ausdrückt. https://www.alekseialeinikov.com/blog/bigquery-graph-architecture-2026.webp BigQuery Graph liegt ohne ETL über vorhandenen Tabellen, aber GQL erfordert eine Reservierung mit Enterprise oder Enterprise Plus; On-Demand erhält nur die Funktion GRAPH_EXPAND. https://www.alekseialeinikov.com/blog/graph-analytics-vs-operational-2026.webp Zwei Graphprodukte, eine Sprache: Spanner Graph beantwortet Nachbarschaftsfragen in Millisekunden, BigQuery Graph beantwortet Fragen über den ganzen Graphen in Sekunden bis Stunden, mit Datenbewegung in beide Richtungen. 2026-09-02 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/data/do-you-need-a-vector-database-postgres-vs-dedicated-2026 https://www.alekseialeinikov.com/blog/vector-database-2026.webp Do You Need a Vector Database? Postgres vs Dedicated in 2026 https://www.alekseialeinikov.com/blog/vector-search-exact-vs-approximate-2026.webp Exact search scans every vector for perfect recall; HNSW builds a multilayer graph for the best speed-recall tradeoff at higher memory cost; IVFFlat clusters vectors into lists that are cheaper to build but weaker per unit of recall. https://www.alekseialeinikov.com/blog/vector-filter-trap-2026.webp The filtering trap: an approximate index scan returns a fixed candidate list, then the WHERE clause filters it, so a selective condition can leave only a handful of rows; iterative scans keep scanning until enough results are found. https://www.alekseialeinikov.com/blog/vector-database-decision-2026.webp Decision path: start with Postgres and pgvector, and move to a dedicated vector database only when a specific mechanism breaks — tenant isolation at scale, index memory beyond a single instance, or an operational model you do not want to own. 2026-08-28 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/data/brauchst-du-eine-vektordatenbank-postgres-vs-dedizierte-2026 https://www.alekseialeinikov.com/blog/vector-database-2026.webp Brauchst du eine Vektordatenbank? Postgres vs. dedizierte Engines 2026 https://www.alekseialeinikov.com/blog/vector-search-exact-vs-approximate-2026.webp Exakte Suche prüft jeden Vektor für perfekte Recall; HNSW baut einen mehrschichtigen Graphen mit dem besten Verhältnis von Geschwindigkeit zu Recall bei höherem Speicherbedarf; IVFFlat clustert Vektoren in Listen, die günstiger zu bauen, pro Recall-Einheit aber schwächer sind. https://www.alekseialeinikov.com/blog/vector-filter-trap-2026.webp Die Filter-Falle: Der approximative Index-Scan liefert eine feste Kandidatenliste, danach filtert die WHERE-Klausel, sodass bei selektiven Bedingungen nur eine Handvoll Zeilen übrig bleibt; iterative Scans scannen weiter, bis genug Treffer gefunden sind. https://www.alekseialeinikov.com/blog/vector-database-decision-2026.webp Entscheidungspfad: Mit Postgres und pgvector starten und erst zu einer dedizierten Vektordatenbank wechseln, wenn ein konkreter Mechanismus bricht — Mandantenisolation im großen Maßstab, Index-Speicher jenseits einer einzelnen Instanz oder ein Betriebsmodus, den du nicht selbst tragen willst. 2026-08-28 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/data/cloud-bigtable-2026-when-wide-column-beats-bigquery-spanner-cassandra https://www.alekseialeinikov.com/blog/bigtable-2026.webp Cloud Bigtable in 2026: When Wide-Column Beats BigQuery, Spanner, and Cassandra https://www.alekseialeinikov.com/blog/bigtable-how-it-works-2026.webp How Bigtable works: one sorted wide-column table split into tablets, each served by a node, all backed by immutable SSTables on Colossus storage that is separated from compute. https://www.alekseialeinikov.com/blog/bigtable-positioning-2026.webp Positioning matrix: Bigtable and Cassandra/DynamoDB sit in key/point access + wide-column NoSQL; Spanner adds SQL and transactions; BigQuery covers full-table analytics. https://www.alekseialeinikov.com/blog/bigtable-row-key-2026.webp Row-key design: sequential keys send every write to one hot node while others sit idle; a high-cardinality prefix spreads writes evenly so throughput scales linearly. 2026-07-13 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/data/cloud-bigtable-2026-wann-wide-column-bigquery-spanner-cassandra-schlaegt https://www.alekseialeinikov.com/blog/bigtable-2026.webp Cloud Bigtable 2026: Wann Wide-Column BigQuery, Spanner und Cassandra schlägt https://www.alekseialeinikov.com/blog/bigtable-how-it-works-2026.webp Wie Bigtable funktioniert: eine sortierte Wide-Column-Tabelle, aufgeteilt in Tablets, je von einem Node bedient, gestützt auf immutable SSTables auf Colossus-Speicher, der von Compute getrennt ist. https://www.alekseialeinikov.com/blog/bigtable-positioning-2026.webp Positionierungsmatrix: Bigtable und Cassandra/DynamoDB liegen bei Key-/Punktzugriff + Wide-Column-NoSQL; Spanner ergänzt SQL und Transaktionen; BigQuery deckt Full-Table-Analytics ab. https://www.alekseialeinikov.com/blog/bigtable-row-key-2026.webp Row-Key-Design: sequenzielle Keys schicken jeden Write an einen heißen Node, während andere untätig sind; ein hochkardinales Präfix verteilt Writes gleichmäßig, sodass der Durchsatz linear skaliert. 2026-07-13 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/data/data-governance-gcp-2026 https://www.alekseialeinikov.com/blog/data-governance-gcp-2026.webp Data Governance on GCP in 2026: Who Can See This Data? https://www.alekseialeinikov.com/blog/data-governance-layers-2026.webp The four layers of data governance on GCP: IAM as the identity base, Knowledge Catalog for cataloging and lineage, Sensitive Data Protection for finding PII, BigQuery policy tags for column access, and VPC Service Controls as the perimeter — each mapped to one of the four governance questions. https://www.alekseialeinikov.com/blog/data-governance-access-flow-2026.webp BigQuery column-level access flow: a query hits the dataset ACL first, then each sensitive column's policy tag is checked against the user's Fine-Grained Reader role; the user needs both, and dynamic data masking can return a masked value instead of an error. https://www.alekseialeinikov.com/blog/data-governance-decision-2026.webp Data governance decision guide: start with cataloging if you cannot find your data, with Sensitive Data Protection discovery if you cannot find your PII, with policy tags if columns are all-or-nothing, and with VPC Service Controls if exfiltration is the risk. 2026-07-20 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/data/data-governance-gcp-2026-wer-sieht-welche-daten https://www.alekseialeinikov.com/blog/data-governance-gcp-2026.webp Data Governance auf GCP 2026: Wer darf diese Daten sehen? https://www.alekseialeinikov.com/blog/data-governance-layers-2026.webp Die vier Ebenen der Data Governance auf GCP: IAM als Identitätsbasis, Knowledge Catalog für Katalogisierung und Lineage, Sensitive Data Protection zum Finden von PII, BigQuery Policy Tags für Spaltenzugriff und VPC Service Controls als Perimeter — jede einer der vier Governance-Fragen zugeordnet. https://www.alekseialeinikov.com/blog/data-governance-access-flow-2026.webp BigQuery-Zugriffsfluss auf Spaltenebene: Eine Abfrage trifft zuerst die Dataset-ACL, dann wird das Policy Tag jeder sensiblen Spalte gegen die Fine-Grained-Reader-Rolle des Nutzers geprüft; der Nutzer braucht beides, und dynamische Datenmaskierung kann einen maskierten Wert statt eines Fehlers zurückgeben. https://www.alekseialeinikov.com/blog/data-governance-decision-2026.webp Entscheidungshilfe Data Governance: mit Katalogisierung starten, wenn Sie Ihre Daten nicht finden; mit Sensitive-Data-Protection-Discovery, wenn Sie Ihre PII nicht finden; mit Policy Tags, wenn Spalten Alles-oder-nichts sind; mit VPC Service Controls, wenn Exfiltration das Risiko ist. 2026-07-20 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/data/iceberg-vs-delta-lake-2026 https://www.alekseialeinikov.com/blog/iceberg-vs-delta-lake-2026.webp Iceberg vs Delta Lake in 2026: A Plain Guide to Picking One https://www.alekseialeinikov.com/blog/what-is-a-table-format-2026.webp A folder of Parquet files versus the same files with a table format metadata layer on top. https://www.alekseialeinikov.com/blog/iceberg-vs-delta-lake-differences-2026.webp What Iceberg and Delta Lake really do differently: partitioning, governance and interoperability. 2026-09-08 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/data/iceberg-vs-delta-lake-2026-vergleich https://www.alekseialeinikov.com/blog/iceberg-vs-delta-lake-2026.webp Iceberg vs. Delta Lake 2026: Ein verständlicher Leitfaden zur Auswahl https://www.alekseialeinikov.com/blog/what-is-a-table-format-2026.webp Ein Ordner mit Parquet-Dateien gegenüber denselben Dateien mit einer Tabellenformat-Metadatenschicht darüber. https://www.alekseialeinikov.com/blog/iceberg-vs-delta-lake-differences-2026.webp Was Iceberg und Delta Lake wirklich unterscheidet: Partitionierung, Governance und Interoperabilität. 2026-09-08 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/data/postgres-vs-mysql-2026 https://www.alekseialeinikov.com/blog/postgres-vs-mysql-2026.webp Postgres vs MySQL in 2026: Performance, Syntax and the Real Differences https://www.alekseialeinikov.com/blog/postgres-mysql-architecture-2026.webp Where Postgres and MySQL win: clustered vs heap storage and their different MVCC costs. 2026-09-10 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/data/postgres-vs-mysql-2026-vergleich https://www.alekseialeinikov.com/blog/postgres-vs-mysql-2026.webp Postgres vs. MySQL 2026: Performance, Syntax und die echten Unterschiede https://www.alekseialeinikov.com/blog/postgres-mysql-architecture-2026.webp Wo Postgres und MySQL gewinnen: geclusterte gegen Heap-Speicherung und ihre unterschiedlichen MVCC-Kosten. 2026-09-10 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/data/sql-query-optimization-2026-faster-database-performance https://www.alekseialeinikov.com/blog/1_wgu4URsmjNvqHJqogQorFA.webp SQL Query Optimization in 2026: 7 Simple Techniques for Faster Database Performance 2026-06-28 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/data/sql-query-optimierung-2026-schnellere-datenbank-performance https://www.alekseialeinikov.com/blog/1_wgu4URsmjNvqHJqogQorFA.webp SQL Query Optimization 2026: 7 einfache Techniken fuer schnellere Datenbank-Performance 2026-06-28 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/data/sql-vs-nosql-2026-database-types-acid-base-how-to-choose https://www.alekseialeinikov.com/blog/sql-vs-nosql-2026.webp SQL vs NoSQL in 2026: Database Types, ACID vs BASE, and How to Actually Choose https://www.alekseialeinikov.com/blog/sql-vs-nosql-types-2026.webp Each database family optimised for a different access pattern: lookups, documents, writes at scale, relationships, time ranges, similarity. https://www.alekseialeinikov.com/blog/sql-vs-nosql-acid-base-2026.webp ACID favours correctness and strong consistency; BASE favours availability and scale, accepting eventual consistency — CAP forces the trade under partitions. https://www.alekseialeinikov.com/blog/sql-vs-nosql-choose-2026.webp A decision path: lookups by key, ad-hoc questions, relationships, time ranges, or strong transactions each point to a different database family. 2026-08-04 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/data/sql-vs-nosql-2026-datenbanktypen-acid-base-richtig-waehlen https://www.alekseialeinikov.com/blog/sql-vs-nosql-2026.webp SQL vs. NoSQL 2026: Datenbanktypen, ACID vs. BASE und wie man richtig wählt https://www.alekseialeinikov.com/blog/sql-vs-nosql-types-2026.webp Jede Datenbankfamilie für ein anderes Zugriffsmuster optimiert: Lookups, Dokumente, Schreiben im großen Maßstab, Beziehungen, Zeitbereiche, Ähnlichkeit. https://www.alekseialeinikov.com/blog/sql-vs-nosql-acid-base-2026.webp ACID bevorzugt Korrektheit und starke Konsistenz; BASE bevorzugt Verfügbarkeit und Skalierung und akzeptiert eventuelle Konsistenz — CAP erzwingt den Tausch bei Partitionen. https://www.alekseialeinikov.com/blog/sql-vs-nosql-choose-2026.webp Ein Entscheidungspfad: Lookups per Schlüssel, Ad-hoc-Fragen, Beziehungen, Zeitbereiche oder starke Transaktionen zeigen je auf eine andere Datenbankfamilie. 2026-08-04 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/devops/build-a-tiny-linux-container-without-docker-2026 https://www.alekseialeinikov.com/blog/1_PVv90FbaIT1ESF_fGrDs9g.webp Build a Tiny Linux Container without Docker in 2026 2026-06-28 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/devops/kleinen-linux-container-ohne-docker-bauen-2026 https://www.alekseialeinikov.com/blog/1_PVv90FbaIT1ESF_fGrDs9g.webp Einen kleinen Linux-Container ohne Docker bauen 2026 2026-06-28 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/devops/dora-metrics-2026-why-four-became-five https://www.alekseialeinikov.com/blog/dora-metrics-2026.webp DORA Metrics in 2026: Why Four Became Five (and What Most Dashboards Still Get Wrong) https://www.alekseialeinikov.com/blog/dora-metrics-five-2026.webp The five DORA metrics grouped into throughput (change lead time, deployment frequency, failed deployment recovery time) and instability (change fail rate, deployment rework rate), showing that recovery time moved into throughput and rework rate was added in 2024 https://www.alekseialeinikov.com/blog/dora-metrics-gaming-2026.webp Each of the five DORA metrics paired with the specific way teams game it when it becomes a performance target: splitting commits, measuring from merge, excluding hard incidents, not recording failures, and reclassifying hotfixes as planned work 2026-08-19 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/devops/dora-metriken-2026-warum-aus-vier-fuenf-wurden https://www.alekseialeinikov.com/blog/dora-metrics-2026.webp DORA-Metriken 2026: Warum aus vier fünf wurden (und was die meisten Dashboards falsch machen) https://www.alekseialeinikov.com/blog/dora-metrics-five-2026.webp Die fünf DORA-Metriken, gruppiert in Durchsatz (Change Lead Time, Deployment-Frequenz, Failed Deployment Recovery Time) und Instabilität (Change Fail Rate, Deployment Rework Rate); die Recovery-Zeit wechselte zum Durchsatz, die Rework Rate kam 2024 hinzu https://www.alekseialeinikov.com/blog/dora-metrics-gaming-2026.webp Jede der fünf DORA-Metriken mit der konkreten Art, wie Teams sie manipulieren, sobald sie zum Leistungsziel wird: Commits aufteilen, ab Merge messen, schwere Vorfälle ausschließen, Fehler nicht erfassen und Hotfixes als geplante Arbeit umdeklarieren 2026-08-19 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/devops/gitops-argo-cd-automated-kubernetes-deployments-2026 https://www.alekseialeinikov.com/blog/1_rtOYGLjRX6Sdgdwn8aoW4w.webp GitOps with Argo CD: Automated Kubernetes Deployments in 2026 https://www.alekseialeinikov.com/blog/1_Kz3ZeShaGjOEpaH81HNJUQ.webp A GitOps workflow separates application CI from cluster reconciliation, with Argo CD applying the desired state from Git. 2026-06-28 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/devops/gitops-mit-argo-cd-automatisierte-kubernetes-deployments-2026 https://www.alekseialeinikov.com/blog/1_rtOYGLjRX6Sdgdwn8aoW4w.webp GitOps mit Argo CD: Automatisierte Kubernetes-Deployments 2026 https://www.alekseialeinikov.com/blog/1_Kz3ZeShaGjOEpaH81HNJUQ.webp Ein GitOps-Workflow trennt Application CI von Cluster-Reconciliation, während Argo CD den gewünschten Zustand aus Git anwendet. 2026-06-28 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/devops/k3s-vs-k0s-vs-microk8s-vs-rke2-2026 https://www.alekseialeinikov.com/blog/lightweight-kubernetes-2026.webp k3s vs k0s vs MicroK8s vs RKE2: Which Kubernetes to Install When You Don't Need the Full One https://www.alekseialeinikov.com/blog/lightweight-k8s-anatomy-2026.webp Side-by-side anatomy of k3s, k0s, MicroK8s and RKE2 showing packaging, default datastore, how control plane components run, default CNI and which components come bundled https://www.alekseialeinikov.com/blog/lightweight-k8s-decision-2026.webp Decision guide mapping constraints to distributions: regulated production and audits to RKE2, edge sites with thin connectivity to k3s, fleet standardisation and control plane isolation to k0s, Ubuntu workstation development to MicroK8s 2026-08-20 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/devops/k3s-vs-k0s-vs-microk8s-vs-rke2-2026-vergleich https://www.alekseialeinikov.com/blog/lightweight-kubernetes-2026.webp k3s vs k0s vs MicroK8s vs RKE2: Welches Kubernetes, wenn das volle nicht nötig ist https://www.alekseialeinikov.com/blog/lightweight-k8s-anatomy-2026.webp Anatomie von k3s, k0s, MicroK8s und RKE2 im direkten Vergleich: Paketierung, Standard-Datastore, Ausführung der Control-Plane-Komponenten, Standard-CNI und mitgelieferte Bestandteile https://www.alekseialeinikov.com/blog/lightweight-k8s-decision-2026.webp Entscheidungshilfe: regulierte Produktion und Audits zu RKE2, Edge-Standorte mit dünner Anbindung zu k3s, Flottenstandardisierung und Control-Plane-Isolation zu k0s, Ubuntu-Workstation-Entwicklung zu MicroK8s 2026-08-20 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/devops/kubernetes-autoscaling-2026-hpa-vpa-cluster-autoscaler https://www.alekseialeinikov.com/blog/kubernetes-autoscaling-2026.webp Kubernetes Autoscaling: Three Controllers That Do Not Talk to Each Other https://www.alekseialeinikov.com/blog/kubernetes-autoscaling-layers-2026.webp The three Kubernetes autoscaling layers — HPA changing replica count, VPA changing Pod size, and the node autoscaler changing machine count — all reading the same resource requests with no coordination between them https://www.alekseialeinikov.com/blog/kubernetes-autoscaling-feedback-2026.webp The feedback loop between HPA and VPA on the same CPU resource: VPA lowers the request, measured utilization rises, HPA adds replicas, per-Pod usage falls, and VPA lowers the request again 2026-08-26 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/devops/kubernetes-autoscaling-2026-hpa-vpa-cluster-autoscaler-vergleich https://www.alekseialeinikov.com/blog/kubernetes-autoscaling-2026.webp Kubernetes Autoscaling: Drei Controller, die nicht miteinander reden https://www.alekseialeinikov.com/blog/kubernetes-autoscaling-layers-2026.webp Die drei Ebenen des Kubernetes-Autoscalings — HPA ändert die Replica-Anzahl, VPA die Pod-Größe, der Node-Autoscaler die Maschinenanzahl — alle lesen dieselben Resource Requests, ohne sich abzustimmen https://www.alekseialeinikov.com/blog/kubernetes-autoscaling-feedback-2026.webp Die Rückkopplung zwischen HPA und VPA auf derselben CPU-Ressource: VPA senkt den Request, die gemessene Auslastung steigt, HPA fügt Replicas hinzu, der Verbrauch pro Pod sinkt, VPA senkt den Request erneut 2026-08-26 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/devops/microvms-firecracker-vs-gvisor-secure-workloads-2026 https://www.alekseialeinikov.com/blog/microvms-firecracker-vs-gvisor-2026.webp microVMs Explained: Firecracker vs gVisor for Secure Workloads in 2026 2026-06-27 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/devops/microvms-firecracker-vs-gvisor-sichere-workloads-2026 https://www.alekseialeinikov.com/blog/microvms-firecracker-vs-gvisor-2026.webp microVMs erklärt: Firecracker vs. gVisor für sichere Workloads 2026 2026-06-27 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/devops/opentofu-vs-terraform-2026 https://www.alekseialeinikov.com/blog/opentofu-vs-terraform-2026.webp OpenTofu vs Terraform in 2026: Is the Fork Worth Switching To? https://www.alekseialeinikov.com/blog/opentofu-fork-timeline-2026.webp Timeline of the fork: Terraform up to 1.5 was MPL; in August 2023 HashiCorp relicensed to BUSL and the community forked the last MPL version into OpenTofu under the Linux Foundation. Terraform went to HCP Terraform and IBM ownership; OpenTofu added state encryption and reached 1.12. https://www.alekseialeinikov.com/blog/opentofu-vs-terraform-features-2026.webp Three-column comparison: OpenTofu-only features (state encryption, provider for_each, -exclude, open registry), shared foundation (HCL, providers, plan/apply, modules, testing), and Terraform-only features (HCP Terraform, Stacks, Sentinel, official support). 2026-07-17 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/devops/opentofu-vs-terraform-lohnt-der-fork-2026 https://www.alekseialeinikov.com/blog/opentofu-vs-terraform-2026.webp OpenTofu vs Terraform 2026: Lohnt sich der Fork? https://www.alekseialeinikov.com/blog/opentofu-fork-timeline-2026.webp Zeitleiste des Forks: Terraform bis 1.5 war MPL; im August 2023 lizenzierte HashiCorp auf BUSL um und die Community forkte die letzte MPL-Version in OpenTofu unter der Linux Foundation. Terraform ging zu HCP Terraform und IBM-Besitz; OpenTofu ergänzte State-Verschlüsselung und erreichte 1.12. https://www.alekseialeinikov.com/blog/opentofu-vs-terraform-features-2026.webp Drei-Spalten-Vergleich: OpenTofu-Alleinstellungsmerkmale (State-Verschlüsselung, provider for_each, -exclude, offene Registry), gemeinsame Grundlage (HCL, Provider, plan/apply, Module, Testing) und Terraform-Alleinstellungsmerkmale (HCP Terraform, Stacks, Sentinel, offizieller Support). 2026-07-17 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/devops/platform-engineering-on-kubernetes-2026 https://www.alekseialeinikov.com/blog/platform-engineering-kubernetes-2026.webp Platform Engineering on Kubernetes: What It Actually Is (and How to Build the Platform) https://www.alekseialeinikov.com/blog/platform-engineering-golden-path-2026.webp A diagram contrasting two developers. On the left, "without a platform", one developer is surrounded by many tools — Kubernetes, Helm, Terraform, CI/CD, networking, secrets, security — labelled high cognitive load. On the right, "with a platform", the developer interacts with a single self-service interface labelled golden path, while the platform absorbs all the underlying tools. https://www.alekseialeinikov.com/blog/platform-engineering-idp-layers-2026.webp A layered stack diagram of an Internal Developer Platform on Kubernetes. From the bottom: cloud infrastructure (GKE, compute, network); orchestration and configuration (Kubernetes, Crossplane, Helm, Kustomize); continuous delivery (Argo CD, GitOps); and the self-service interface at the top (developer portal like Backstage, templates, platform CLI and API). Two vertical bars span all layers on the right: guardrails (policy-as-code, RBAC, security) and observability (metrics, logs, traces). https://www.alekseialeinikov.com/blog/platform-engineering-decision-2026.webp A decision tree titled "Do you actually need a platform?". First question: do multiple teams keep re-solving the same infrastructure problems? Second: is developer cognitive load measurably slowing delivery? Third: do you have enough scale to fund a platform team that treats the platform as a product? If the answers are no, the recommendation is good templates plus a README beat a platform you can't maintain. If yes to all, build an IDP and run it as a product. 2026-07-23 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/devops/platform-engineering-auf-kubernetes-2026 https://www.alekseialeinikov.com/blog/platform-engineering-kubernetes-2026.webp Platform Engineering auf Kubernetes: Was es wirklich ist (und wie man die Plattform baut) https://www.alekseialeinikov.com/blog/platform-engineering-golden-path-2026.webp Ein Diagramm, das zwei Entwickler gegenüberstellt. Links, „ohne Plattform", ist ein Entwickler von vielen Werkzeugen umgeben — Kubernetes, Helm, Terraform, CI/CD, Networking, Secrets, Security — beschriftet mit hoher kognitiver Last. Rechts, „mit Plattform", interagiert der Entwickler mit einer einzigen Self-Service-Schnittstelle, beschriftet als Golden Path, während die Plattform alle darunterliegenden Werkzeuge absorbiert. https://www.alekseialeinikov.com/blog/platform-engineering-idp-layers-2026.webp Ein geschichtetes Stack-Diagramm einer Internal Developer Platform auf Kubernetes. Von unten: Cloud-Infrastruktur (GKE, Compute, Netzwerk); Orchestrierung und Konfiguration (Kubernetes, Crossplane, Helm, Kustomize); Continuous Delivery (Argo CD, GitOps); und die Self-Service-Schnittstelle oben (Entwicklerportal wie Backstage, Templates, Plattform-CLI und -API). Zwei vertikale Balken spannen rechts über alle Ebenen: Leitplanken (Policy-as-Code, RBAC, Security) und Observability (Metriken, Logs, Traces). https://www.alekseialeinikov.com/blog/platform-engineering-decision-2026.webp Ein Entscheidungsbaum mit dem Titel „Brauchst du wirklich eine Plattform?". Erste Frage: Lösen mehrere Teams dieselben Infra-Probleme immer wieder? Zweite: Bremst kognitive Last die Delivery messbar? Dritte: Hast du genug Größe, um ein Plattform-Team zu finanzieren, das die Plattform als Produkt behandelt? Wenn die Antworten nein sind, lautet die Empfehlung: gute Templates plus eine README schlagen eine Plattform, die du nicht warten kannst. Wenn ja zu allen, bau eine IDP und betreib sie als Produkt. 2026-07-23 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/devops/podman-2026-rootless-daemonless-containers-without-docker https://www.alekseialeinikov.com/blog/podman-2026.webp Podman in 2026: Rootless, Daemonless Containers Without Docker https://www.alekseialeinikov.com/blog/podman-daemon-vs-daemonless-2026.webp Docker routes every container through a single always-on root daemon; Podman forks each container directly with no daemon in the middle. https://www.alekseialeinikov.com/blog/podman-rootless-userns-2026.webp Inside the container a process is UID 0; the user namespace maps it to an unprivileged UID like 100000 on the host, so an escape lands as a nobody. https://www.alekseialeinikov.com/blog/podman-pod-quadlet-systemd-2026.webp A pod feeds a Quadlet .container unit, which systemd reads directly to start on boot, restart on crash, and log to journald. 2026-07-11 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/devops/podman-2026-rootless-daemonlose-container-ohne-docker https://www.alekseialeinikov.com/blog/podman-2026.webp Podman 2026: Rootless und daemonlose Container ohne Docker https://www.alekseialeinikov.com/blog/podman-daemon-vs-daemonless-2026.webp Docker leitet jeden Container durch einen einzigen dauerhaft laufenden Root-Daemon; Podman forkt jeden Container direkt, ohne Daemon dazwischen. https://www.alekseialeinikov.com/blog/podman-rootless-userns-2026.webp Im Container ist ein Prozess UID 0; der User-Namespace mappt ihn auf eine unprivilegierte UID wie 100000 auf dem Host, sodass ein Ausbruch als Niemand landet. https://www.alekseialeinikov.com/blog/podman-pod-quadlet-systemd-2026.webp Ein Pod speist eine Quadlet-.container-Unit, die systemd direkt liest, um beim Boot zu starten, nach Absturz neu zu starten und in journald zu loggen. 2026-07-11 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/devops/sbom-wont-stop-the-next-log4j-2026 https://www.alekseialeinikov.com/blog/sbom-log4j-2026.webp SBOM Won't Stop the Next Log4j — Here's What Actually Would https://www.alekseialeinikov.com/blog/sbom-log4j-timeline-2026.webp The same SBOM, two days apart: a one-time file misses Log4Shell; continuous re-scanning catches it the hour the CVE drops. https://www.alekseialeinikov.com/blog/sbom-four-layers-2026.webp Four layers turn an SBOM from a filing-cabinet artifact into a defense: inventory, correlate, verify, triage. 2026-07-29 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/devops/sbom-stoppt-das-naechste-log4j-nicht-2026 https://www.alekseialeinikov.com/blog/sbom-log4j-2026.webp Eine SBOM stoppt das nächste Log4j nicht — das hier schon https://www.alekseialeinikov.com/blog/sbom-log4j-timeline-2026.webp Dieselbe SBOM, zwei Tage auseinander: eine einmalige Datei verpasst Log4Shell; kontinuierliches Neu-Scannen fängt es in der Stunde ab, in der das CVE erscheint. https://www.alekseialeinikov.com/blog/sbom-four-layers-2026.webp Vier Schichten machen aus einer SBOM statt eines Aktenschrank-Artefakts eine Verteidigung: Inventar, Korrelation, Verifikation, Triage. 2026-07-29 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/devops/secure-gitlab-cicd-hardening-playbook-2026 https://www.alekseialeinikov.com/blog/1_Xn6x2Hbgnag1z1PEywDD-Q.webp Secure GitLab CI/CD in 2026: A Practical Hardening Playbook 2026-06-27 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/devops/sichere-gitlab-cicd-pipelines-hardening-playbook-2026 https://www.alekseialeinikov.com/blog/1_Xn6x2Hbgnag1z1PEywDD-Q.webp Sichere GitLab CI/CD-Pipelines 2026: Ein praktisches Hardening-Playbook 2026-06-27 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/programming/biome-2026-replace-eslint-prettier-benchmark https://www.alekseialeinikov.com/blog/biome-2026.webp I Replaced ESLint + Prettier with Biome in 2026 — Here Is the Benchmark https://www.alekseialeinikov.com/blog/biome-toolchain-2026.webp Before: eslint, prettier, and a stack of plugins with four config files. After: one Biome binary and one biome.json. https://www.alekseialeinikov.com/blog/biome-benchmark-2026.webp Benchmark: Biome formats roughly 25x faster than Prettier and lints around 20x faster than ESLint on the same codebase. 2026-07-05 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/programming/biome-2026-eslint-prettier-ersetzen-benchmark https://www.alekseialeinikov.com/blog/biome-2026.webp Ich habe ESLint + Prettier 2026 durch Biome ersetzt — hier ist der Benchmark https://www.alekseialeinikov.com/blog/biome-toolchain-2026.webp Vorher: eslint, prettier und ein Stapel Plugins mit vier Konfigurationsdateien. Nachher: ein Biome-Binary und eine biome.json. https://www.alekseialeinikov.com/blog/biome-benchmark-2026.webp Benchmark: Biome formatiert rund 25x schneller als Prettier und lintet rund 20x schneller als ESLint auf derselben Codebasis. 2026-07-05 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/programming/es-toolkit-2026-lodash-replacement-2x-faster-97-smaller https://www.alekseialeinikov.com/blog/es-toolkit-2026.webp es-toolkit in 2026: The Lodash Replacement That's 2× Faster and 97% Smaller 2026-06-30 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/programming/es-toolkit-2026-die-lodash-alternative-2x-schneller-97-kleiner https://www.alekseialeinikov.com/blog/es-toolkit-2026.webp es-toolkit 2026: Die Lodash-Alternative, die 2x schneller und 97% kleiner ist 2026-06-30 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/programming/how-many-threads-go-really-uses-runtime-investigation-2026 https://www.alekseialeinikov.com/blog/1_eAmuMJ-Iq34Gj8-7T8STTw.webp How Many Threads Does Go Really Use? A 2026 Runtime Investigation 2026-06-28 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/programming/wie-viele-threads-nutzt-go-wirklich-runtime-untersuchung-2026 https://www.alekseialeinikov.com/blog/1_eAmuMJ-Iq34Gj8-7T8STTw.webp Wie viele Threads nutzt Go wirklich? Eine Runtime-Untersuchung 2026 2026-06-28 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/programming/linkedin-scraper-vs-dataset-marketplace-data-engineer-honest-review-2026 https://www.alekseialeinikov.com/blog/1_vW1iBMVXLD0NRG7iYYQXmA.webp LinkedIn Scraping vs. Buying a Dataset in 2026: 3 Days of Code I Could Have Skipped https://www.alekseialeinikov.com/blog/1_7IEFqzFsxZMPs47qR3hmtw.webp Bright Data's Dataset Marketplace turns web data collection into a ready-to-use dataset workflow. https://www.alekseialeinikov.com/blog/1_yvrxo6IaqqvbMGcLiOYOJg.webp The prototype is easy. Production scraping is where the problems begin. https://www.alekseialeinikov.com/blog/1_cLfItZ9OG5uqw4ShvjF7mQ.webp What begins as a simple scraper quickly turns into a full data pipeline with its own maintenance burden. https://www.alekseialeinikov.com/blog/1_5ci3FOIEAnLGhqnXyeOWFA.webp Messy fields, duplicates, missing values, and inconsistent formats quickly turn scraping into data cleaning work. https://www.alekseialeinikov.com/blog/1_cj9bg5OQ9lEZ9L5LmEmxOQ.webp Example of LinkedIn datasets available in Bright Data's Dataset Marketplace, including people profiles, company information, job listings, posts, and profile-job listing datasets. https://www.alekseialeinikov.com/blog/1_KQNEB643aBr-fvmHxeBOEQ.webp Bright Data's Dataset Marketplace includes e-commerce datasets for products, reviews, sellers, pricing, availability, and search results. https://www.alekseialeinikov.com/blog/1_Yl0FKdjUf0VQNxk0VsZh5Q.webp Ready-made datasets are useful only when they can be delivered in formats your data stack actually uses. https://www.alekseialeinikov.com/blog/1_cOY2A31xSoPHVjb5GUlVRQ.webp For ML and RAG, the real value is not just collecting data - it is turning structured datasets into searchable, usable knowledge. https://www.alekseialeinikov.com/blog/1_xCBWg8vSpoou4o4xJVxCEg.webp The marketplace search view, showing available datasets matching the query. https://www.alekseialeinikov.com/blog/1_rNNX2a1ml5KrVC84XWQUKg.webp Dataset dictionary view for LinkedIn company information, showing field names, descriptions, data types, and fill rates. https://www.alekseialeinikov.com/blog/1_n_W5zWzHly8cORMKQ8EypA.webp The downloaded sample shows the dataset as actual rows and columns, not just a product description. https://www.alekseialeinikov.com/blog/1_fbWDb2yzMCuhS3rLgwkJpQ.webp Filtering before ingestion means I can narrow a large dataset to the records that actually match my use case. https://www.alekseialeinikov.com/blog/1_8cp8gd0apUbh3KTtyrigcA.webp The trade-off: maintenance burden vs. time to usable data. https://www.alekseialeinikov.com/blog/1_n6EnnYIR6xsYFDwln29Y8A.webp A RAG assistant becomes useful when structured company and job data can be retrieved, ranked, and turned into grounded answers. 2026-06-28 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/programming/linkedin-scraper-vs-dataset-marketplace-data-engineer-ehrlicher-vergleich-2026 https://www.alekseialeinikov.com/blog/1_vW1iBMVXLD0NRG7iYYQXmA.webp LinkedIn-Scraping vs. Datensatz kaufen 2026: 3 Tage Code, die ich hätte sparen können https://www.alekseialeinikov.com/blog/1_7IEFqzFsxZMPs47qR3hmtw.webp Bright Data's Dataset Marketplace verwandelt die Web-Datenerfassung in einen fertigen Datensatz-Workflow. https://www.alekseialeinikov.com/blog/1_yvrxo6IaqqvbMGcLiOYOJg.webp Das Prototyp ist einfach. Produktions-Scraping ist der Punkt, wo die Probleme beginnen. https://www.alekseialeinikov.com/blog/1_cLfItZ9OG5uqw4ShvjF7mQ.webp Was als einfacher Scraper beginnt, wird schnell zu einer vollständigen Datenpipeline mit eigenem Wartungsaufwand. https://www.alekseialeinikov.com/blog/1_5ci3FOIEAnLGhqnXyeOWFA.webp Unordentliche Felder, Duplikate, fehlende Werte und inkonsistente Formate machen aus dem Scraping schnell Datenbereinigungsarbeit. https://www.alekseialeinikov.com/blog/1_cj9bg5OQ9lEZ9L5LmEmxOQ.webp Beispiel der LinkedIn-Datensätze im Bright Data Dataset Marketplace, einschließlich Personenprofile, Unternehmensinformationen, Stellenangebote, Beiträge und Profil-Stellenangebots-Datensätze. https://www.alekseialeinikov.com/blog/1_KQNEB643aBr-fvmHxeBOEQ.webp Bright Data's Dataset Marketplace umfasst E-Commerce-Datensätze für Produkte, Bewertungen, Verkäufer, Preise, Verfügbarkeit und Suchergebnisse. https://www.alekseialeinikov.com/blog/1_Yl0FKdjUf0VQNxk0VsZh5Q.webp Fertige Datensätze sind nur dann nützlich, wenn sie in Formaten geliefert werden können, die der eigene Datenstapel tatsächlich nutzt. https://www.alekseialeinikov.com/blog/1_cOY2A31xSoPHVjb5GUlVRQ.webp Für ML und RAG liegt der eigentliche Wert nicht nur im Sammeln von Daten, sondern darin, strukturierte Datensätze in durchsuchbares, nutzbares Wissen zu verwandeln. https://www.alekseialeinikov.com/blog/1_xCBWg8vSpoou4o4xJVxCEg.webp Die Marketplace-Suchansicht zeigt verfügbare Datensätze, die zur Anfrage passen. https://www.alekseialeinikov.com/blog/1_rNNX2a1ml5KrVC84XWQUKg.webp Datenwörterbuch-Ansicht für LinkedIn-Unternehmensinformationen, mit Feldnamen, Beschreibungen, Datentypen und Füllraten. https://www.alekseialeinikov.com/blog/1_n_W5zWzHly8cORMKQ8EypA.webp Das heruntergeladene Sample zeigt den Datensatz als tatsächliche Zeilen und Spalten, nicht nur als Produktbeschreibung. https://www.alekseialeinikov.com/blog/1_fbWDb2yzMCuhS3rLgwkJpQ.webp Filtern vor der Einspeisung bedeutet, ich kann einen großen Datensatz auf die Datensätze einschränken, die tatsächlich zu meinem Anwendungsfall passen. https://www.alekseialeinikov.com/blog/1_8cp8gd0apUbh3KTtyrigcA.webp Der Kompromiss: Wartungsaufwand versus Zeit bis zu nutzbaren Daten. https://www.alekseialeinikov.com/blog/1_n6EnnYIR6xsYFDwln29Y8A.webp Ein RAG-Assistent wird nützlich, wenn strukturierte Unternehmens- und Jobdaten abgerufen, gerankt und in fundierte Antworten umgewandelt werden können. 2026-06-28 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/programming/jest-to-vitest-migration https://www.alekseialeinikov.com/blog/jest-to-vitest-migration.webp Migrating from Jest to Vitest: What Actually Breaks https://www.alekseialeinikov.com/blog/jest-vitest-breakage-classes.webp Three columns: loud failures like done callbacks and jest namespace types, silent wrong behaviour like mockReset and hook order, and silently missing behaviour like __mocks__ not auto-loading. https://www.alekseialeinikov.com/blog/jest-vitest-mockreset-trap.webp Side-by-side comparison: in Jest mockReset replaces the implementation with an empty function returning undefined; in Vitest it restores the original implementation passed to the mock factory. https://www.alekseialeinikov.com/blog/jest-vitest-should-migrate.webp Checklist: already on Vite, wanting ESM, big watch loop are good reasons to migrate; being on webpack or plain Node, or relying on Jest-only plugins, are reasons to reconsider. 2026-09-18 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/programming/von-jest-zu-vitest-migrieren https://www.alekseialeinikov.com/blog/jest-to-vitest-migration.webp Von Jest zu Vitest migrieren: Was wirklich kaputtgeht https://www.alekseialeinikov.com/blog/jest-vitest-breakage-classes.webp Drei Spalten: laute Fehler wie done-Callbacks und jest-Namespace-Typen, still falsches Verhalten wie mockReset und Hook-Reihenfolge, und still fehlendes Verhalten wie nicht automatisch geladene __mocks__. https://www.alekseialeinikov.com/blog/jest-vitest-mockreset-trap.webp Gegenüberstellung: In Jest ersetzt mockReset die Implementierung durch eine leere Funktion, die undefined zurückgibt; in Vitest wird die ursprüngliche Implementierung wiederhergestellt. https://www.alekseialeinikov.com/blog/jest-vitest-should-migrate.webp Checkliste: bereits auf Vite, ESM gewünscht, große Watch-Schleife sprechen für die Migration; webpack oder reines Node und Jest-only-Plugins sprechen dagegen. 2026-09-18 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/programming/nodejs-npm-packages-worth-mastering-in-2026 https://www.alekseialeinikov.com/blog/1_9_8BFHb48R_QC46POGEWAQ.webp 10 Node.js NPM Packages Worth Mastering in 2026 2026-06-28 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/programming/nodejs-npm-pakete-die-man-2026-beherrschen-sollte https://www.alekseialeinikov.com/blog/1_9_8BFHb48R_QC46POGEWAQ.webp 10 Node.js NPM-Pakete, die man 2026 beherrschen sollte 2026-06-28 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/programming/playwright-bright-data-browser-api-kubernetes-scraping-pipeline-2026 https://www.alekseialeinikov.com/blog/1_TmXavGnY5QWAHbzjnOcSMg.webp Production-Grade Playwright Web Scraping on Kubernetes with Bright Data (2026) https://www.alekseialeinikov.com/blog/1_flomKaZffJUzUXDHpGHv_g.webp Bright Data dashboard with Browser API configured. https://www.alekseialeinikov.com/blog/1_phGqG0LNQ8XizkFg7kN3PA.webp The Browser API setup screen provides a Playwright/Puppeteer-compatible **WebSocket** endpoint used to attach to a managed remote browser over CDP. https://www.alekseialeinikov.com/blog/1_ZFYd5WXbueuYRD1toO_vWQ.webp The initial smoke test returned a live DevTools inspection URL, the expected page title, and structured quote data extracted from a JavaScript-rendered page. https://www.alekseialeinikov.com/blog/1_LGMrsz2-aSc9XxlXWmnI3A.webp The Playwright worker packaged as a lightweight **Docker** image before being deployed through Kubernetes. https://www.alekseialeinikov.com/blog/1_SHbMi_JxBJ8UtTgJejzmFA.webp The Kubernetes Job completed successfully, with the pod progressing from container creation to a completed batch run. https://www.alekseialeinikov.com/blog/1_-VBM3U6m2sz5QglQr83PWA.webp Browser API traffic visible in the Bright Data dashboard after the Playwright and Kubernetes test run. https://www.alekseialeinikov.com/blog/1_5N72iFzd4yUUQej7EjXsqA.webp After validating the one-off batch execution, the same scraper was scheduled through a Kubernetes CronJob without changing the application code. 2026-06-28 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/programming/playwright-bright-data-browser-api-kubernetes-scraping-pipeline-2026-de https://www.alekseialeinikov.com/blog/1_TmXavGnY5QWAHbzjnOcSMg.webp Playwright Web Scraping auf Kubernetes produktionsreif betreiben mit Bright Data (2026) https://www.alekseialeinikov.com/blog/1_flomKaZffJUzUXDHpGHv_g.webp Bright Data Dashboard mit konfigurierter Browser API. https://www.alekseialeinikov.com/blog/1_phGqG0LNQ8XizkFg7kN3PA.webp Der Browser-API-Setup-Screen stellt einen Playwright/Puppeteer-kompatiblen **WebSocket**-Endpunkt bereit, über den man sich über CDP mit einem verwalteten Remote-Browser verbindet. https://www.alekseialeinikov.com/blog/1_ZFYd5WXbueuYRD1toO_vWQ.webp Der initiale Smoke-Test gab eine Live-DevTools-Inspektions-URL, den erwarteten Seitentitel und strukturierte Zitat-Daten zurück, die von einer JavaScript-gerenderten Seite extrahiert wurden. https://www.alekseialeinikov.com/blog/1_LGMrsz2-aSc9XxlXWmnI3A.webp Der Playwright-Worker als leichtgewichtiges **Docker**-Image verpackt, bevor er über Kubernetes deployed wird. https://www.alekseialeinikov.com/blog/1_SHbMi_JxBJ8UtTgJejzmFA.webp Der Kubernetes Job wurde erfolgreich abgeschlossen, der Pod schritt von der Container-Erstellung zu einem abgeschlossenen Batch-Lauf voran. https://www.alekseialeinikov.com/blog/1_-VBM3U6m2sz5QglQr83PWA.webp Browser-API-Traffic im Bright Data Dashboard nach dem Playwright- und Kubernetes-Testlauf sichtbar. https://www.alekseialeinikov.com/blog/1_5N72iFzd4yUUQej7EjXsqA.webp Nach der Validierung der einmaligen Batch-Ausführung wurde derselbe Scraper über einen Kubernetes CronJob geplant, ohne den Anwendungscode zu ändern. 2026-06-28 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/programming/pytest-in-practice-2026-python-testing-guide https://www.alekseialeinikov.com/blog/1_6jVZVawi-1UakWgiGHmqcA.webp Pytest in Practice 2026: A Python Developer Testing Guide 2026-06-28 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/programming/pytest-in-der-praxis-2026-python-testing-guide https://www.alekseialeinikov.com/blog/1_6jVZVawi-1UakWgiGHmqcA.webp Pytest in der Praxis 2026: Testing Guide fuer Python Entwickler 2026-06-28 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/programming/python-data-visualization-libraries https://www.alekseialeinikov.com/blog/python-dataviz-libraries.webp Five Python Libraries for Data Visualization: Which One and When https://www.alekseialeinikov.com/blog/pyviz-where-rendered.webp Two lanes: matplotlib and seaborn render in Python and produce png, svg or pdf files; plotly, bokeh and altair serialise to JSON and let plotly.js, BokehJS or Vega-Lite render interactive HTML in the browser. https://www.alekseialeinikov.com/blog/pyviz-pick-by-job.webp Decision table mapping five jobs to libraries: quick look at data to matplotlib, statistical figure to seaborn, hover and zoom to plotly, dashboard reacting to live Python to bokeh, many small charts to altair. https://www.alekseialeinikov.com/blog/pyviz-constraints.webp Table of one constraint per library: matplotlib verbose by design, seaborn set_theme is global, plotly static export needs Chrome, bokeh callbacks need a server, altair MaxRowsError at 5000 rows. 2026-09-17 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/programming/python-bibliotheken-datenvisualisierung https://www.alekseialeinikov.com/blog/python-dataviz-libraries.webp Fünf Python-Bibliotheken für Datenvisualisierung: Welche wann https://www.alekseialeinikov.com/blog/pyviz-where-rendered.webp Zwei Spalten: matplotlib und seaborn rendern in Python und erzeugen png-, svg- oder pdf-Dateien; plotly, bokeh und altair serialisieren nach JSON und lassen plotly.js, BokehJS oder Vega-Lite interaktives HTML im Browser rendern. https://www.alekseialeinikov.com/blog/pyviz-pick-by-job.webp Entscheidungstabelle, die fünf Aufgaben Bibliotheken zuordnet: schneller Blick auf Daten zu matplotlib, statistische Abbildung zu seaborn, Hover und Zoom zu plotly, Dashboard mit Live-Python zu bokeh, viele kleine Diagramme zu altair. https://www.alekseialeinikov.com/blog/pyviz-constraints.webp Tabelle mit je einer Einschränkung pro Bibliothek: matplotlib ist bewusst ausführlich, seaborns set_theme ist global, plotly braucht Chrome für Static Export, bokeh-Callbacks brauchen einen Server, altair wirft MaxRowsError bei 5000 Zeilen. 2026-09-17 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/programming/stop-passing-raw-dicts-around-python-models-2026 https://www.alekseialeinikov.com/blog/1_KtSgqz0LdjgRisqN8r-Skw.webp Stop Passing Raw Dicts Around in Python: Safer Models for 2026 2026-06-28 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/programming/python-dicts-unter-kontrolle-modelle-statt-rohdaten-2026 https://www.alekseialeinikov.com/blog/1_KtSgqz0LdjgRisqN8r-Skw.webp Python Dicts unter Kontrolle: Modelle statt Rohdaten in 2026 2026-06-28 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/programming/python-error-handling-2026-try-except-or-if-checks https://www.alekseialeinikov.com/blog/1_mwQ7EQlFjdjOPr6ydQgeQw.webp Python Error Handling in 2026: Try-Except or If-Checks? 2026-06-27 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/programming/python-fehlerbehandlung-2026-try-except-oder-if-checks https://www.alekseialeinikov.com/blog/1_mwQ7EQlFjdjOPr6ydQgeQw.webp Python-Fehlerbehandlung 2026: Try-Except oder If-Checks? 2026-06-27 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/programming/python-joblib-2026-processes-threads-memmap-caching https://www.alekseialeinikov.com/blog/1_5zCVGXEgQqgBFsEhXdxUQg.webp Python Joblib in 2026: Processes, Threads, Memmap, and Caching https://www.alekseialeinikov.com/blog/1_J2vbt8Ms-HEtQTm8ysW6jg.webp Joblib vs multiprocessing: fewer moving parts for common parallel workloads. 2026-06-28 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/programming/python-joblib-2026-prozesse-threads-memmap-caching https://www.alekseialeinikov.com/blog/1_5zCVGXEgQqgBFsEhXdxUQg.webp Python Joblib 2026: Prozesse, Threads, Memmap und Caching https://www.alekseialeinikov.com/blog/1_J2vbt8Ms-HEtQTm8ysW6jg.webp Joblib vs multiprocessing: weniger bewegliche Teile fuer haeufige parallele Workloads. 2026-06-28 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/programming/python-web-scraping-without-proxy-management-bright-data-web-unlocker https://www.alekseialeinikov.com/blog/1_w7Uj0jkEPVXGH8bKgUXHUg.webp Python Web Scraping Without Proxy Management: Bright Data Web Unlocker API (2026) 2026-06-28 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/programming/python-web-scraping-ohne-proxy-verwaltung-bright-data-web-unlocker https://www.alekseialeinikov.com/blog/1_w7Uj0jkEPVXGH8bKgUXHUg.webp Python Web Scraping ohne Proxy-Verwaltung: Bright Data Web Unlocker API (2026) 2026-06-28 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/programming/scraper-studio-vs-apify-vs-diy-2026 https://www.alekseialeinikov.com/blog/scraper-studio-2026.webp Scraper Studio vs Apify vs DIY: Which Web Scraping Path Fits Your Team in 2026 https://www.alekseialeinikov.com/blog/scraper-studio-three-paths-2026.webp One decision, three paths: Scraper Studio, Apify, and a DIY Scrapy plus Playwright stack, compared on build time, code ownership, and who fixes breakages. https://www.alekseialeinikov.com/blog/scraper-studio-self-healing-2026.webp The Scraper Studio self-healing loop: build once, the site changes and fields return null, one click triggers AI Self-Healing on the code you own, and the scraper is running again under the same collector ID. https://www.alekseialeinikov.com/blog/scraper-studio-agent-flow-2026.webp Agent-native flow: a coding agent calls the Bright Data CLI, an AI Agent builds the scraper and output schema, and returns a typed JSON collector — the agent never runs proxies or browsers itself. https://www.alekseialeinikov.com/blog/scraper-studio-data-out-2026.webp One scraper, many destinations: a defined output schema exported as JSON, NDJSON, CSV, or Parquet and delivered to a webhook, Amazon S3, Google Cloud Storage, or Azure Blob. 2026-07-09 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/programming/scraper-studio-vs-apify-vs-diy-welcher-weg-2026 https://www.alekseialeinikov.com/blog/scraper-studio-2026.webp Scraper Studio vs Apify vs DIY: Welcher Web-Scraping-Weg passt 2026 zu Ihrem Team https://www.alekseialeinikov.com/blog/scraper-studio-three-paths-2026.webp Eine Entscheidung, drei Wege: Scraper Studio, Apify und ein DIY-Stack aus Scrapy plus Playwright, verglichen nach Bauzeit, Code-Eigentum und wer Brüche repariert. https://www.alekseialeinikov.com/blog/scraper-studio-self-healing-2026.webp Der Self-Healing-Kreislauf von Scraper Studio: einmal bauen, die Seite ändert sich und Felder liefern null, ein Klick löst KI-Self-Healing am Code aus, der Ihnen gehört, und der Scraper läuft wieder unter derselben Collector-ID. https://www.alekseialeinikov.com/blog/scraper-studio-agent-flow-2026.webp Agent-nativer Ablauf: Ein Coding-Agent ruft die Bright Data CLI auf, ein KI-Agent baut Scraper und Ausgabeschema und liefert einen typisierten JSON-Collector — der Agent betreibt selbst nie Proxys oder Browser. https://www.alekseialeinikov.com/blog/scraper-studio-data-out-2026.webp Ein Scraper, viele Ziele: ein definiertes Ausgabeschema, exportiert als JSON, NDJSON, CSV oder Parquet und geliefert an einen Webhook, Amazon S3, Google Cloud Storage oder Azure Blob. 2026-07-09 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/programming/why-i-moved-from-nestjs-to-fastify-and-ddd-in-2025 https://www.alekseialeinikov.com/blog/1_ojXE7_N63DX3V7zC9Haj_g.webp Why I Moved from Nest.js to Fastify and DDD in 2026 2026-06-28 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/programming/warum-ich-2025-von-nestjs-zu-fastify-und-ddd-gewechselt-bin https://www.alekseialeinikov.com/blog/1_ojXE7_N63DX3V7zC9Haj_g.webp Warum ich von Nest.js zu Fastify und DDD gewechselt bin 2026-06-28 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/programming/web-scraping-vs-web-crawling-2026 https://www.alekseialeinikov.com/blog/scraping-vs-crawling-2026.webp Web Scraping vs Web Crawling: The Real Difference (2026) https://www.alekseialeinikov.com/blog/scraping-pipeline-2026.webp One pipeline, two stages: a crawler discovers product URLs from a seed page, then a scraper extracts fields from each URL into a clean, structured dataset. 2026-07-03 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/programming/web-scraping-vs-web-crawling-der-unterschied-2026 https://www.alekseialeinikov.com/blog/scraping-vs-crawling-2026.webp Web Scraping vs. Web Crawling: Der echte Unterschied (2026) https://www.alekseialeinikov.com/blog/scraping-pipeline-2026.webp Eine Pipeline, zwei Stufen: Ein Crawler entdeckt Produkt-URLs von einer Seed-Seite, dann extrahiert ein Scraper aus jeder URL die Felder in einen sauberen, strukturierten Datensatz. 2026-07-03 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/security/user-level-permission-controls-mcp-tool-access-gateway-2026 https://www.alekseialeinikov.com/blog/mcp-permission-controls-2026.webp User-Level Permission Controls for MCP Tool Access with an Enterprise MCP Gateway https://www.alekseialeinikov.com/blog/mcp-gateway-tool-filtering-2026.webp An MCP gateway as a single choke point: AI clients authenticate with a virtual key, the gateway applies a per-key allow-list of MCP tools, and enforces it at both inference and tool-execution time. https://www.alekseialeinikov.com/blog/mcp-gateway-edge-enforcement-2026.webp A single control plane, enforced everywhere: Bifrost defines identity, virtual keys and MCP policy centrally; an Edge agent on each machine syncs that policy and enforces allow or deny on local MCP servers directly on the device. 2026-07-06 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/security/benutzerbezogene-zugriffskontrolle-mcp-tools-gateway-2026 https://www.alekseialeinikov.com/blog/mcp-permission-controls-2026.webp Benutzerbezogene Zugriffskontrolle für MCP-Tools mit einem Enterprise-MCP-Gateway https://www.alekseialeinikov.com/blog/mcp-gateway-tool-filtering-2026.webp Ein MCP-Gateway als einziger Engpass: KI-Clients authentifizieren sich mit einem Virtual Key, das Gateway wendet eine Allow-Liste von MCP-Tools pro Schlüssel an und setzt sie sowohl beim Inferenzieren als auch bei der Tool-Ausführung durch. https://www.alekseialeinikov.com/blog/mcp-gateway-edge-enforcement-2026.webp Eine Kontrollebene, überall durchgesetzt: Bifrost definiert Identität, Virtual Keys und MCP-Richtlinie zentral; ein Edge-Agent auf jeder Maschine synchronisiert diese Richtlinie und setzt Allow oder Deny für lokale MCP-Server direkt auf dem Gerät durch. 2026-07-06 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/security/build-your-own-cspm-gcp-security-command-center-vs-open-source-2026 https://www.alekseialeinikov.com/blog/cspm-gcp-cover-2026.webp Build Your Own CSPM on GCP: Security Command Center vs Open Source https://www.alekseialeinikov.com/blog/cspm-gcp-architecture-2026.webp Two roads to the same cloud posture on GCP: the built-in Security Command Center, and a do-it-yourself open-source pipeline. https://www.alekseialeinikov.com/blog/cspm-gcp-scc-vs-oss-2026.webp Security Command Center versus an open-source CSPM stack, compared by cost, effort, coverage, multi-cloud, customization and threat detection. 2026-07-05 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/security/eigenes-cspm-auf-gcp-security-command-center-vs-open-source-2026 https://www.alekseialeinikov.com/blog/cspm-gcp-cover-2026.webp Eigenes CSPM auf GCP bauen: Security Command Center vs. Open Source https://www.alekseialeinikov.com/blog/cspm-gcp-architecture-2026.webp Zwei Wege zur selben Cloud-Posture auf GCP: das eingebaute Security Command Center und eine selbstgebaute Open-Source-Pipeline. https://www.alekseialeinikov.com/blog/cspm-gcp-scc-vs-oss-2026.webp Security Command Center gegen einen Open-Source-CSPM-Stack, verglichen nach Kosten, Aufwand, Abdeckung, Multi-Cloud, Anpassbarkeit und Threat Detection. 2026-07-05 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/security/first-24-hours-google-cloud-security-command-center-2026 https://www.alekseialeinikov.com/blog/scc-first-24-hours-2026.webp The First 24 Hours with Security Command Center: What Nobody Tells You 2026-06-29 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/security/erste-24-stunden-google-cloud-security-command-center-2026 https://www.alekseialeinikov.com/blog/scc-first-24-hours-2026.webp Die ersten 24 Stunden mit dem Security Command Center: Was niemand sagt 2026-06-29 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/security/falco-production-runtime-security-without-alert-fatigue-2026 https://www.alekseialeinikov.com/blog/falco-2026.webp Falco in Production: Runtime Security Without Drowning in Alerts https://www.alekseialeinikov.com/blog/falco-layers-2026.webp Four security layers: IaC, image scanning and admission control evaluate artefacts; only runtime detection evaluates behaviour. https://www.alekseialeinikov.com/blog/falco-noise-2026.webp Default rules describe generally-suspicious behaviour that is often perfectly normal in a specific cluster — the gap is yours to close. https://www.alekseialeinikov.com/blog/falco-routing-2026.webp Route by severity: only genuinely actionable rules reach a pager, everything else goes to a searchable log. 2026-08-11 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/security/falco-in-produktion-runtime-security-ohne-alarm-flut-2026 https://www.alekseialeinikov.com/blog/falco-2026.webp Falco in Produktion: Runtime-Security ohne Alarm-Flut https://www.alekseialeinikov.com/blog/falco-layers-2026.webp Vier Sicherheitsschichten: IaC, Image-Scanning und Admission Control bewerten Artefakte; nur Runtime-Erkennung bewertet Verhalten. https://www.alekseialeinikov.com/blog/falco-noise-2026.webp Standardregeln beschreiben allgemein verdächtiges Verhalten, das in einem konkreten Cluster oft völlig normal ist — die Lücke musst du schließen. https://www.alekseialeinikov.com/blog/falco-routing-2026.webp Nach Schweregrad routen: nur wirklich handlungsrelevante Regeln erreichen einen Pager, alles andere geht in ein durchsuchbares Log. 2026-08-11 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/security/is-keycloak-free-keycloak-vs-authentik-2026 https://www.alekseialeinikov.com/blog/keycloak-authentik-2026.webp Is Keycloak Free? Keycloak vs authentik and What Each Really Costs https://www.alekseialeinikov.com/blog/keycloak-authentik-license-2026.webp authentik licence states escalate from warnings to a read-only instance after six weeks. https://www.alekseialeinikov.com/blog/keycloak-authentik-scim-2026.webp SCIM has two directions: authentik covers both, Keycloak currently covers only inbound. https://www.alekseialeinikov.com/blog/keycloak-authentik-cost-2026.webp Where effort actually goes on a self-hosted identity provider: the licence is the smallest slice. 2026-08-13 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/security/ist-keycloak-kostenlos-keycloak-vs-authentik-2026 https://www.alekseialeinikov.com/blog/keycloak-authentik-2026.webp Ist Keycloak kostenlos? Keycloak vs. authentik und die wahren Kosten https://www.alekseialeinikov.com/blog/keycloak-authentik-license-2026.webp authentiks Lizenzzustände eskalieren von Warnungen bis zur Read-only-Instanz nach sechs Wochen. https://www.alekseialeinikov.com/blog/keycloak-authentik-scim-2026.webp SCIM hat zwei Richtungen: authentik deckt beide ab, Keycloak derzeit nur die eingehende. https://www.alekseialeinikov.com/blog/keycloak-authentik-cost-2026.webp Wohin der Aufwand bei einem selbst gehosteten Identity Provider wirklich geht: die Lizenz ist der kleinste Anteil. 2026-08-13 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/security/stop-storing-jwts-in-localstorage-cookie-auth-for-spas-2026 https://www.alekseialeinikov.com/blog/1_ldHCmzpjsA_NbFP8XHPwbg.webp Stop Storing JWTs in LocalStorage: Cookie Auth for SPAs in 2026 2026-06-28 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/security/jwt-nicht-in-localstorage-cookie-auth-fuer-spas-2026 https://www.alekseialeinikov.com/blog/1_ldHCmzpjsA_NbFP8XHPwbg.webp JWT nicht in LocalStorage speichern: Cookie Auth fuer SPAs 2026 2026-06-28 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/security/kill-service-account-keys-workload-identity-federation-2026 https://www.alekseialeinikov.com/blog/workload-identity-federation-2026.webp Kill Your Service Account Keys: Workload Identity Federation on GCP in 2026 https://www.alekseialeinikov.com/blog/wif-token-exchange-2026.webp How a keyless login works: your workload presents an OIDC token, the pool and provider check the claims, Google STS exchanges it for a short-lived token, and your service account is impersonated — no key ever created. https://www.alekseialeinikov.com/blog/wif-attribute-condition-2026.webp Danger versus safe: without an attribute_condition any GitHub repo can assume your identity; with assertion.repository_owner locked to your org, only your repos can exchange a token. https://www.alekseialeinikov.com/blog/wif-field-rule-2026.webp The field rule: go keyless and stay keyless on Google Cloud. 2026-07-01 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/security/service-account-schluessel-abschaffen-workload-identity-federation-2026 https://www.alekseialeinikov.com/blog/workload-identity-federation-2026.webp Schluss mit Service-Account-Schlüsseln: Workload Identity Federation auf GCP 2026 https://www.alekseialeinikov.com/blog/wif-token-exchange-2026.webp So funktioniert ein schlüsselloses Login: Dein Workload legt ein OIDC-Token vor, Pool und Provider prüfen die Claims, Google STS tauscht es gegen ein kurzlebiges Token, und dein Service-Account wird impersoniert — es wird nie ein Schlüssel erzeugt. https://www.alekseialeinikov.com/blog/wif-attribute-condition-2026.webp Gefahr versus sicher: Ohne attribute_condition kann jedes GitHub-Repo deine Identität annehmen; mit assertion.repository_owner auf deine Organisation gesperrt können nur deine Repos ein Token tauschen. https://www.alekseialeinikov.com/blog/wif-field-rule-2026.webp Die Feldregel: schlüssellos werden und schlüssellos bleiben auf Google Cloud. 2026-07-01 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/security/npm-supply-chain-attack-mitigation-2026 https://www.alekseialeinikov.com/blog/npm-supply-chain-attack-mitigation-2026.webp npm Supply Chain Attack Mitigation: What Actually Works https://www.alekseialeinikov.com/blog/npm-audit-blind-spot-2026.webp Why npm audit reports a clean tree: the advisory gap that this attack class lives inside. https://www.alekseialeinikov.com/blog/npm-trusted-publishing-2026.webp The npm publish path with a long-lived token versus trusted publishing with OIDC. 2026-09-09 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/security/npm-lieferkettenangriffe-abwehren-2026 https://www.alekseialeinikov.com/blog/npm-supply-chain-attack-mitigation-2026.webp npm-Lieferkettenangriffe abwehren: Was wirklich hilft https://www.alekseialeinikov.com/blog/npm-audit-blind-spot-2026.webp Warum npm audit einen sauberen Baum meldet: die Advisory-Lücke, in der diese Angriffsklasse lebt. https://www.alekseialeinikov.com/blog/npm-trusted-publishing-2026.webp Der npm-Veröffentlichungspfad mit langlebigem Token gegenüber Trusted Publishing mit OIDC. 2026-09-09 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/security/opa-vs-kyverno-2026-kubernetes-policy-engine https://www.alekseialeinikov.com/blog/opa-kyverno-2026.webp OPA vs Kyverno in 2026: Kubernetes Ships Policy Now https://www.alekseialeinikov.com/blog/opa-kyverno-matrix-2026.webp Capability matrix: built-in policies cover admission, but generation, image verification and reporting still need a controller. https://www.alekseialeinikov.com/blog/opa-kyverno-decision-2026.webp A decision path: start with built-in policies, add a controller only for the capabilities they lack. https://www.alekseialeinikov.com/blog/opa-kyverno-webhook-2026.webp Webhook failure modes: Fail blocks the cluster, Ignore silently disables enforcement, built-in policies avoid the choice. 2026-08-12 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/security/opa-vs-kyverno-2026-kubernetes-policy-engine-vergleich https://www.alekseialeinikov.com/blog/opa-kyverno-2026.webp OPA vs. Kyverno 2026: Kubernetes liefert Policies jetzt selbst https://www.alekseialeinikov.com/blog/opa-kyverno-matrix-2026.webp Fähigkeitsmatrix: eingebaute Policies decken Admission ab, aber Generierung, Image-Prüfung und Reporting brauchen weiterhin einen Controller. https://www.alekseialeinikov.com/blog/opa-kyverno-decision-2026.webp Ein Entscheidungspfad: mit eingebauten Policies beginnen, einen Controller nur für die fehlenden Fähigkeiten ergänzen. https://www.alekseialeinikov.com/blog/opa-kyverno-webhook-2026.webp Webhook-Fehlerfälle: Fail blockiert den Cluster, Ignore schaltet die Durchsetzung still ab, eingebaute Policies umgehen die Wahl. 2026-08-12 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/security/passkeys-vs-passwords-webauthn-how-it-works-2026 https://www.alekseialeinikov.com/blog/passkeys-vs-passwords-2026.webp Passkeys vs Passwords: How WebAuthn Actually Works, Who Builds What, and How to Roll It Out https://www.alekseialeinikov.com/blog/passkeys-registration-flow-2026.webp WebAuthn registration ceremony diagram: relying party sends a challenge, the browser calls navigator.credentials.create, the authenticator generates a key pair on-device and returns the public key, and the server stores only the public key https://www.alekseialeinikov.com/blog/passkeys-login-flow-2026.webp Diagram comparing the same passkey login attempt on the real site yourapp.com versus a look-alike phishing domain: on the real origin the authenticator signs the challenge and a session is created, on the phishing origin the authenticator refuses to sign and there is nothing to steal https://www.alekseialeinikov.com/blog/passkeys-sync-fabrics-2026.webp Diagram of passkey sync fabrics in 2026: Apple iCloud Keychain, Google Password Manager, Microsoft Windows Hello and Entra ID, and cross-platform password managers like 1Password and Bitwarden, bridged only by FIDO2 CTAP2 hybrid transport via QR code 2026-09-14 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/security/passkeys-vs-passwoerter-wie-webauthn-funktioniert-2026 https://www.alekseialeinikov.com/blog/passkeys-vs-passwords-2026.webp Passkeys vs. Passwörter: Wie WebAuthn wirklich funktioniert, wer was anbietet und wie man es einführt https://www.alekseialeinikov.com/blog/passkeys-registration-flow-2026.webp Diagramm der WebAuthn-Registrierungszeremonie: Die Relying Party sendet eine Challenge, der Browser ruft navigator.credentials.create auf, der Authenticator erzeugt ein Schlüsselpaar auf dem Gerät und gibt den öffentlichen Schlüssel zurück, der Server speichert nur den öffentlichen Schlüssel https://www.alekseialeinikov.com/blog/passkeys-login-flow-2026.webp Diagramm, das denselben Passkey-Login-Versuch auf der echten Seite yourapp.com mit einer Phishing-Fake-Domain vergleicht: Auf dem echten Origin signiert der Authenticator die Challenge und eine Session entsteht, auf der Phishing-Domain verweigert der Authenticator die Signatur und es gibt nichts zu stehlen https://www.alekseialeinikov.com/blog/passkeys-sync-fabrics-2026.webp Diagramm der Passkey-Sync-Ökosysteme 2026: Apple iCloud Keychain, Google Passwortmanager, Microsoft Windows Hello und Entra ID sowie plattformübergreifende Passwortmanager wie 1Password und Bitwarden, verbunden nur über FIDO2-CTAP2-Hybrid-Transport per QR-Code 2026-09-14 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/security/prompt-injection-defense-2026-lethal-trifecta-test https://www.alekseialeinikov.com/blog/prompt-injection-2026.webp The Lethal Trifecta: A Practical Test for Prompt Injection Risk https://www.alekseialeinikov.com/blog/lethal-trifecta-legs-2026.webp Three legs of the lethal trifecta: private data access, untrusted content exposure, and external communication. Any two are survivable; all three together allow an attacker to exfiltrate data through a prompt injection. https://www.alekseialeinikov.com/blog/exfiltration-allowlist-failures-2026.webp Exfiltration allow-lists that failed in production: open redirects on trusted domains, expired domains still listed, logging services on default lists, and the vendor's own API used as the channel. https://www.alekseialeinikov.com/blog/prompt-injection-defence-2026.webp Prompt injection defence checklist: cut the exfiltration leg, scope credentials to non-production, allow-list individual tools, require human approval for side effects, and design for survivable compromise. 2026-08-31 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/security/prompt-injection-abwehr-2026-lethal-trifecta-test https://www.alekseialeinikov.com/blog/prompt-injection-2026.webp Die Lethal Trifecta: Ein praktischer Test für Prompt-Injection-Risiko https://www.alekseialeinikov.com/blog/lethal-trifecta-legs-2026.webp Die drei Beine der Lethal Trifecta: Zugriff auf private Daten, Kontakt mit nicht vertrauenswürdigen Inhalten und externe Kommunikation. Zwei sind überlebbar; alle drei zusammen erlauben Angreifern die Exfiltration per Prompt Injection. https://www.alekseialeinikov.com/blog/exfiltration-allowlist-failures-2026.webp Gescheiterte Exfiltrations-Allow-Lists aus der Praxis: offene Redirects auf vertrauenswürdigen Domains, abgelaufene aber weiterhin gelistete Domains, Logging-Dienste auf Standardlisten und die eigene API des Anbieters als Kanal. https://www.alekseialeinikov.com/blog/prompt-injection-defence-2026.webp Checkliste zur Prompt-Injection-Abwehr: Exfiltrationsbein kappen, Zugangsdaten auf Nicht-Produktion beschränken, einzelne Werkzeuge freigeben, menschliche Freigabe bei Seiteneffekten und überlebbare Kompromittierung einplanen. 2026-08-31 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/security/siem-pricing-wazuh-vs-sentinel-vs-google-secops-2026 https://www.alekseialeinikov.com/blog/siem-pricing-2026.webp Wazuh vs Microsoft Sentinel vs Google SecOps: The SIEM You Pick Is the Bill You Get https://www.alekseialeinikov.com/blog/siem-meters-2026.webp Three SIEM pricing meters compared: Microsoft Sentinel billing gigabytes ingested per day, Google SecOps selling packages capped by detection rule counts, and Wazuh billing agent counts or nothing at all when self-hosted https://www.alekseialeinikov.com/blog/siem-incentives-2026.webp How each SIEM pricing model changes team behaviour: volume pricing pushes teams to filter logs, agent pricing pushes them to limit endpoint coverage, rule-count limits push them to consolidate detections, and self-hosting pushes cost into engineering time 2026-08-24 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/security/siem-preise-wazuh-vs-sentinel-vs-google-secops-2026 https://www.alekseialeinikov.com/blog/siem-pricing-2026.webp Wazuh vs Microsoft Sentinel vs Google SecOps: Das SIEM, das Sie wählen, ist die Rechnung, die Sie bekommen https://www.alekseialeinikov.com/blog/siem-meters-2026.webp Drei SIEM-Preiszähler im Vergleich: Microsoft Sentinel rechnet aufgenommene Gigabyte pro Tag ab, Google SecOps verkauft Pakete mit Obergrenzen für Detection-Regeln, und Wazuh rechnet Agenten ab oder gar nichts, wenn selbst gehostet https://www.alekseialeinikov.com/blog/siem-incentives-2026.webp Wie jedes SIEM-Preismodell das Teamverhalten verändert: Volumenpreise drängen zum Filtern von Logs, Agentenpreise zur Begrenzung der Endpunktabdeckung, Regel-Obergrenzen zur Konsolidierung von Detections und Selbsthosting verlagert Kosten in Ingenieurszeit 2026-08-24 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics/security/tokenization-vs-encryption-2026-what-takes-data-out-of-scope https://www.alekseialeinikov.com/blog/tokenization-2026.webp Tokenization vs Encryption: What Actually Takes Data Out of Scope https://www.alekseialeinikov.com/blog/tokenization-pci-2026.webp PCI DSS scope shrinks across your estate but concentrates in the token vault, which becomes the highest-value target. https://www.alekseialeinikov.com/blog/tokenization-gdpr-2026.webp Tokenization is pseudonymisation under GDPR — the data stays personal, and every obligation stays with it. https://www.alekseialeinikov.com/blog/tokenization-tradeoffs-2026.webp Deterministic tokens preserve joins but leak frequency; random tokens leak nothing but break analytics. 2026-08-10 monthly 0.6 https://www.alekseialeinikov.com/de/blog/topics/security/tokenisierung-vs-verschluesselung-2026-was-daten-aus-dem-scope-nimmt https://www.alekseialeinikov.com/blog/tokenization-2026.webp Tokenisierung vs. Verschlüsselung: Was Daten wirklich aus dem Scope nimmt https://www.alekseialeinikov.com/blog/tokenization-pci-2026.webp Der PCI-DSS-Scope schrumpft über die Systemlandschaft, konzentriert sich aber im Token-Vault, der zum wertvollsten Ziel wird. https://www.alekseialeinikov.com/blog/tokenization-gdpr-2026.webp Tokenisierung ist Pseudonymisierung nach DSGVO — die Daten bleiben personenbezogen, und alle Pflichten bleiben bestehen. https://www.alekseialeinikov.com/blog/tokenization-tradeoffs-2026.webp Deterministische Token erhalten Joins, verraten aber Häufigkeiten; zufällige Token verraten nichts, brechen aber Analytics. 2026-08-10 monthly 0.6 https://www.alekseialeinikov.com/en/blog/topics 2026-09-18 weekly 0.8 https://www.alekseialeinikov.com/de/blog/topics 2026-09-18 weekly 0.8 https://www.alekseialeinikov.com/en/blog/topics/programming 2026-09-18 weekly 0.7 https://www.alekseialeinikov.com/de/blog/topics/programming 2026-09-18 weekly 0.7 https://www.alekseialeinikov.com/en/blog/topics/cloud 2026-09-18 weekly 0.7 https://www.alekseialeinikov.com/de/blog/topics/cloud 2026-09-18 weekly 0.7 https://www.alekseialeinikov.com/en/blog/topics/devops 2026-09-18 weekly 0.7 https://www.alekseialeinikov.com/de/blog/topics/devops 2026-09-18 weekly 0.7 https://www.alekseialeinikov.com/en/blog/topics/data 2026-09-18 weekly 0.7 https://www.alekseialeinikov.com/de/blog/topics/data 2026-09-18 weekly 0.7 https://www.alekseialeinikov.com/en/blog/topics/ai 2026-09-18 weekly 0.7 https://www.alekseialeinikov.com/de/blog/topics/ai 2026-09-18 weekly 0.7 https://www.alekseialeinikov.com/en/blog/topics/security 2026-09-18 weekly 0.7 https://www.alekseialeinikov.com/de/blog/topics/security 2026-09-18 weekly 0.7 https://www.alekseialeinikov.com/en/blog/topics/architecture 2026-09-18 weekly 0.7 https://www.alekseialeinikov.com/de/blog/topics/architecture 2026-09-18 weekly 0.7 https://www.alekseialeinikov.com/en/blog/topics/career 2026-09-18 weekly 0.7 https://www.alekseialeinikov.com/de/blog/topics/career 2026-09-18 weekly 0.7