The industry is really excited about the possibilities with this, and there have been projects around observability and traffic management that have proven how powerful this functionality is.

So let's get into how this technology works.

So let's draw a server from an operating system perspective.

I'm going to break it up into logical layers.

And I'm going to start with the kernel layer.

So that's this layer in the middle here.

And this is the core of an operating system, and it goes in between the other layers.

Then I'm going to draw a physical layer down here.

And this represents all of the physical aspects of the server.

So there could be things like the network, and the storage, and the memory down here.

Now the kernel, it knows how to address all of these physical components of the server.

And then a layer above that is going to be the user layer.

This is the layer where applications are installed and run.

And these applications need to have universal ability to talk to the server components to do what they need to do.

Now an application doesn't want to know how to talk to every single type of network interface card that exists out there.

So it just has to worry about talking to the kernel.

And then the kernel can worry about the communications from there.

Now this communication happens as events, and eBPF is event-driven.

Inside of the kernel, there are events that can happen when a system call is made in between the kernel and user land. eBPF functions can then be triggered at the time of an event in order to do something.

Now the kernel is meant to be very stable as a lot of things rely on it, and it needs to be rock solid.

And so one reason why eBPF is so exciting is that it provides extensibility at a layer where normally it would be quite difficult to implement.

Normally this would require kernel modules to extend functionality.

Kernel modules are difficult to maintain because there are changes with each kernel revision that can often break compatibility.

And depending on your risk tolerance, you may not even want to do this in production in case there are bugs in the kernel module that you want to install.

With eBPF, you can isolate the risk and extend kernel functionality safely.

You also don't have to restart the kernel in order to deploy or undeploy eBPF applications.

Another reason why this is exciting is because of the performance advantages.

Because eBPF runs at the logical junction in between the kernel and hardware devices, it's able to make decisions early when receiving inputs from those devices.

This makes it much more performant while observing traffic.

You can implement hooks into almost any device the kernel is managing, such as memory and networking and storage.

And all of these hook points will be able to have links back to programs running in user space if needed.

So let's talk about the use cases we're seeing with this technology.

Some of the main use cases the industry is excited about is network filtering, observability, and security policies.

Network Filtering eBPF can enforce simple to complex rules very early in the receive path.

This is done very efficiently and tailored to specific processes, network namespaces, or application types.

And this filter can also do egress filtering for the use cases of loss prevention or content filtering.

Observability So I'm just going to draw a couple of magnifying glasses here.

And I'm also going to draw this, which is a representation of a process tree.

And so eBPF can see traffic from any device on the server and the behavior of any process in the process tree.

And so as applications get broken down into microservices, I'm going to represent those with these boxes here.

It's increasingly difficult to bolt on observability in the user land.

And using eBPF, it allows for user space processes such as system monitors, process visualizers, and tracing tools to have a kernel space point of view.

This is an alternative to service meshes, which implement distributed tracing using sidecar proxies, which each add some performance burden.

Instead, performing this at the kernel level has already proven to be advantageous for performance.

Another use case comes around security.

So now that you have all this information, you've identified devices and process flows and you have observability to detect anomalous behavior, you can combine that to trigger policies and you can use eBPF to enforce those policies by asking the kernel to kill processes or you can restrict certain behaviors directly, or you can filter network traffic to and from the device itself. eBPF opens up a number of possibilities that were previously difficult to scale at the same pace of application modernization.

Solutions that take advantage of eBPF will be able to provide a high degree of functionality without the challenges of performance degradation and kernel stability.

So thanks for checking out this Brightboard lesson.

Hit like if you enjoyed this content, leave a comment down below if you have any questions.

Hit subscribe if you want to see more of these and I will see you on the next one.