FaaS is a higher-level kind of Serverless tech where the smallest deployable unit is a Function.
AWS Lambda, Azure Functions, GCP Cloud Function are all super handy, but what if you can't use them for some reason?
Meet OpenFaaS! 🔽
OpenFaaS is an open-source project that turns a piece of lower-level infra into a high-level FaaS solution.
Sounds too abstract?
Kubernetes cluster + OpenFaaS = FaaS API
Single VM + containerd + OpenFaaS = same FaaS API!
where FaaS API is:
- mgmt. methods
- invoke functions
At a high level, OpenFaaS has a universal architecture that allows it to be installed on almost any kind of infra:
API Gateway (concrete) + FaaS-Provider (abstract)
OpenFaaS on Kuberentes
With Kubernetes FaaS-Provider, you get out of the box:
- High-availability
- Horizontal scaling
- Disaster recovery (the only state is in etcd)
OpenFaaS on a VM with containerd
A lightweight setup designed for cheaper servers and IoT devices (e.g Raspberry Pi).
- Blisteringly fast scaling to zero
- Super quick function cold starts
- x10 functions per server (comparing to K8s)
- systemd manages all long-living processes
I've been evaluating OpenFaaS for my personal projects, both from:
Docker relies on containerd, a lower-level container runtime, to run its containers. It is possible to use containerd from the command line directly, but the UX might be quite rough at times.
1. Network namespaces - a Linux facility to virtualize network stacks.
Every container gets its own isolated network stack with (virtual) network devices, a dedicated routing table, a scratch set of iptables rules, and more.
2. Virtual Ethernet Devices (veth) - a means to interconnect network namespaces.
Container's network interfaces are invisible from the host - the latter runs in its own (root) network namespace.
To punch through a network namespace, a special Virtual Ethernet Pair can be used.
3. The need for a (virtual) switch device.
When multiple containers run in the same IP network, leaving the host ends of the veth devices dangling in the root namespaces will make the routes clash. So, you won't be able to reach (some of) the containers.
What is Service Discovery - in general, and in Kubernetes 🧵
Services (in Kubernetes or not) tend to run in multiple instances (containers, pods, VMs). But from the client's standpoint, a service is usually just a single address.
How is this single point of entry achieved?
1⃣ Server-Side Service Discovery
A single load balancer, a.k.a reverse proxy in front of the service's instances, is a common way to solve the Service Discovery problem.
It can be just one Nginx (or HAProxy) or a group of machines sharing the same address 👇
2⃣ Client-Side Service Discovery
The centralized LB layer is relatively easy to provision, but it can become a bottleneck and a single point of failure.
An alternative solution is to distribute the rosters of service addresses to every client and let them pick an instance.
What Happens When You Publish a Container's Port? 🧵
"Port publishing" might be a term coined by Docker.
But "port forwarding" or "port mapping" - as a form of socket redirection - was a widespread trick well before the invention of containers. How are the two different?
Learn about different port forwarding techniques and how container runtimes implement them in this heavily illustrated blog post 👇
1/ When I started with Docker in 2015, I viewed containers as lightweight VMs with fast startups. But this oversimplified view posed risks:
- Misunderstanding capabilities
- Misusing the technology
- Misjudging safety means
2/ The "container = VM" simplification was helpful at first but it quickly became inadequate.
To truly understand what I can and cannot do with containers, I had to dive deep into Docker's internals. However, available materials were either too basic or too complex.
3/ After a lot of trial and error, I came up with a learning path that finally worked for me:
- Linux Containers: The raw details
- Container Images: Why and How
- Container Managers: Docker's role
- Orchestrators: Kubernetes and co.
- Non-Linux Containers: Broadening horizons