For two decades, infrastructure teams watched their systems from the outside. They polled devices with SNMP, scraped logs after the fact, and inferred what happened inside the kernel from the symptoms it leaked. In 2026 that model is being quietly retired. eBPF — the technology that runs small, sandboxed programs directly inside the Linux kernel without patching kernel source or loading fragile modules — has become the default substrate for observability, networking, and runtime security on cloud-native platforms. When packets, system calls, and application traces are all measured at the source, the gap between what the dashboard claims and what actually happened collapses to almost nothing.
The second shift is organisational. Network automation has outgrown its scripting phase and now looks like software engineering: version-controlled intent, tested pipelines, and reconciliation loops that keep production matching a declared state. Add platform engineering — the practice of packaging all of this into a paved road for product teams — and you have the operating model that European and North African companies are converging on. For a services firm in Tunis or a bank in Frankfurt the questions are identical: how do you see everything, change it safely, and prove to a regulator that you did it properly. This post walks through the stack, the honest trade-offs, and what it means to build and staff these teams from Tunisia.
From SNMP to Programmable Kernels: Why 2026 Feels Different
The idea behind eBPF is old, but the conditions that make it dependable are recent. Three of them matter most. First, the kernel verifier: before any eBPF program runs, the kernel statically proves it will terminate and cannot read arbitrary memory, which is what makes running code in kernel space acceptable in production. Second, CO-RE, or Compile Once Run Everywhere, which lets a single compiled probe work across kernel versions instead of forcing a rebuild per host. Third, the maturity of the surrounding projects: Cilium graduated within the CNCF, the eBPF Foundation now shepherds the core, and long-term-support distributions ship kernels new enough to support the features teams actually want.
The practical consequence is that you no longer choose between visibility and overhead. Data-path programs attached at XDP, the eXpress Data Path, can inspect and act on packets before the network stack even processes them, while other probes trace system calls or user-space functions with negligible cost. You measure at the source, once, and feed everything else from that single stream of truth.
The eBPF Observability Stack You Actually Deploy
The ecosystem is broad, so it helps to separate it by job rather than by vendor:
- ▸Network flow visibility: Cilium as the Kubernetes networking layer with Hubble for flow logs and a live service dependency map. You see which workload talked to which, on what port, allowed or denied, without sidecars.
- ▸Runtime security: Tetragon or Falco to observe process execution, file access, and privilege changes as they happen, turning kernel events into detections mapped to frameworks such as MITRE ATT&CK.
- ▸Auto-instrumentation: Grafana Beyla or the OpenTelemetry eBPF work to generate traces and metrics for services you never manually instrumented, which is invaluable for legacy code and third-party binaries.
- ▸Continuous profiling: Parca or Pyroscope to sample CPU and memory across the whole fleet, so a regression shows up as a flame graph rather than a mystery bill.
- ▸Ad-hoc debugging: bpftrace for one-off questions and Pixie for live inspection when an incident cannot wait for a deploy.
The trade-offs are real and worth stating plainly. Kernel-version dependencies still bite on older estates. High-cardinality flow and trace data can become your largest observability cost, so sampling and retention are engineering decisions, not afterthoughts. And centralising all of this raises a data-egress and data-residency question that we return to below.
Network Automation Grows Up: NetDevOps and Intent
If eBPF is how you see the network, automation is how you change it without fear. The centre of gravity in 2026 is model-driven, intent-based operation. Devices and platforms expose structured state through YANG models over NETCONF, RESTCONF, or the streaming telemetry interface gNMI, with OpenConfig giving a vendor-neutral schema. On top sit familiar tools: Ansible and Nornir for orchestration, NAPALM for a common device abstraction, and Terraform or its open fork OpenTofu for anything with an API.
The cultural change is that network configuration now lives in Git and moves through a pipeline. You lint and validate intended state, simulate it against a model of the topology with tools like Batfish, spin the whole lab up in containers with ContainerLab, and only then let a GitOps controller such as Argo CD or Flux reconcile reality toward the merged commit. Open network operating systems, including SONiC and SR Linux, make the switch itself a first-class automation target rather than a black box. The result is that a change is a reviewed pull request with a test result attached, not a late-night session on a serial console.
Platform Engineering Ties It Together
Observability and automation only pay off when product teams can use them without becoming infrastructure experts. That is the job of platform engineering: treat the internal platform as a product, give developers golden paths, and measure whether those paths are actually adopted.
- ▸The portal: Backstage or an equivalent internal developer portal as the front door to services, ownership, and documentation.
- ▸The control plane: Kubernetes with Crossplane or similar, so that requesting a database or a network policy is a declarative API call, not a ticket.
- ▸The paved road: opinionated templates that ship a new service already wired for tracing, logging, mutual TLS, and a default network policy.
- ▸The scorecard: the DORA four keys — deployment frequency, lead time for changes, change failure rate, and time to restore — plus the CNCF Platform Engineering Maturity Model to judge where you honestly are.
Done well, this is Team Topologies in practice: a platform team reducing the cognitive load on stream-aligned teams, not a gatekeeper adding a queue.
Observability as Compliance Evidence: NIS2, DORA, and Zero Trust
For regulated European clients, the strongest argument for this stack is not performance, it is evidence. NIS2 compresses the window in which essential and important entities must report significant incidents, which is impossible to hit if you cannot reconstruct what happened. DORA pushes financial entities toward demonstrable operational resilience and tested recovery, including scrutiny of ICT third parties. The EU Cyber Resilience Act pushes product makers toward secure defaults and a documented vulnerability-handling process.
eBPF flow logs, runtime security events, and immutable pipeline history are exactly the artefacts these regimes ask for. They also make Zero Trust concrete: NIST SP 800-207 describes the model, and Cilium network policy or a service mesh with mutual TLS is how you enforce least-privilege segmentation and prove that a given service could only reach the endpoints it was allowed to. Compliance stops being a spreadsheet exercise and becomes a query against telemetry you already collect.
The Tunisia and North Africa Angle
None of this is theoretical for firms operating between the EU and North Africa. Tunisia offers a deep pool of Linux, networking, and systems engineers, trilingual in Arabic, French, and English, in a timezone that overlaps the European working day almost entirely. That makes nearshored platform and network-reliability teams genuinely practical rather than a cost gimmick, and eBPF-grade skills, while still scarce everywhere, are very much learnable by strong systems people.
Three considerations deserve attention. First, data residency: centralising eBPF telemetry in an EU region keeps European clients comfortable, but egress from North African compute has a cost and latency profile you should design for, not discover. Second, regulation: Tunisia protects personal data under Law 2004-63 with oversight from the INPDP, and it aligns with the Council of Europe Convention 108 tradition, yet it is not on the EU adequacy list, so transfers still ride on Standard Contractual Clauses and a documented transfer assessment. Third, sovereignty expectations from public-sector clients on both shores increasingly favour open, inspectable stacks — precisely the open-source, eBPF-based tooling described here — over opaque appliances.
A 30-60-90 Roadmap and What to Do Monday
A pragmatic sequence for a team starting from a traditional estate:
1. Days 0 to 30: deploy Hubble or an eBPF flow exporter in one non-critical cluster, put every network change for that cluster into Git, and add a linting step. Baseline your DORA metrics honestly. 2. Days 30 to 60: add runtime security with Tetragon or Falco, wire alerts to your incident channel mapped to MITRE ATT&CK techniques, and introduce topology simulation before merges. 3. Days 60 to 90: publish one golden-path service template with tracing, mutual TLS, and a default-deny network policy baked in, and route real telemetry into your NIS2 and DORA evidence store.
A quick comparison to settle one common debate: traditional agent-based APM asks you to instrument code and license per host or per series, and it stops at the application boundary; eBPF auto-instrumentation captures the same golden signals plus kernel and network context with no code changes, at the price of a kernel dependency and a data-volume discipline. For heterogeneous or legacy estates, eBPF usually wins; for a single well-owned codebase, the two can coexist.
What to do Monday: pick one cluster, turn on flow visibility, and put its next network change through a pull request. That single loop — see it, change it in Git, prove it — is the whole philosophy in miniature.
The direction of travel for the rest of 2026 is clear. eBPF is moving up the stack from packets toward application-layer awareness and even toward accelerating parts of the AI-serving data path, while platform engineering absorbs it as just another capability on the paved road. The winners will not be the teams with the most exotic tooling but the ones who close the loop between observing, changing, and proving — and who can staff that loop with engineers close to their European customers. For companies building across the EU and North Africa, that is a chance to skip the appliance era entirely and operate a programmable, inspectable, regulation-ready network from day one.