routeralle

DEVASC: Jämför olika dataformat (XML, JSON, YAML)

2022-06-16T00:00:00Z

XML

“Extensible Markup Language” (XML) är ett textbaserat märkspråk som används för att representera strukturerad information. Språket är plattformsneutralt.

Någon som tidigare har skrivit HTML kan se likheter i strukturen med taggar, attribut och element. Här nedan ser vi hur XML data kan se ut:

<?xml version="1.0" encoding="UTF-8"?>
<device>
  <hostname>LAB01</hostname>
  <ipv6>FE80::903A:1C1A:E802:11E4</ipv6>
  <status>online</status>
</device>

Den första raden i koden ovan kallas för prolog. I denna definierar vi XML version och teckenkodningsattribut.

Efter prologen har vi kroppen (“body”). XML kroppen innehåller våra taggar som är element för data. Vi namnger själva våra element och kan skapa dessa på 4 olika sätt.

Ett tomt element:

<tag/>

Ett element utan innehåll:

<tag></tag>

Ett element med innehåll:

<tag>Vi lär oss!</tag>

Ett element kan även ha attribut:

<tag myAttribute="value"></tag>

XML är väldigt verbalt och enkelt för oss människor att förstå. Det har däremot sina nackdelar, det kan vara svårare att parsa XML data med skriptspråk som exempelvis Python.

JSON

“JavaScript Object Notation” (JSON) är ett lättviktigt datautbytesformat som härstammar från “object literals” i JavaScript.

I följande stycke har jag skrivit om datan i XML exemplet till JSON format:

{
  "device": {
    "hostname": "LAB01",
    "ipv6": "FE80::903A:1C1A:E802:11E4",
    "status": "online"
  }
}

Objekten i JSON skrivs som nyckel-värde-par, de olika paren är separerade av kommatecken. Ett objekt kan ha flera par (som exemplet ovan). Datatyper för värden är heltal, strängar, boolesk eller “null” (värde utan bindning till något).

Eftersom att JSON härstammar från JavaScript behöver vi inte heller tänka på någon form av indentering när vi bygger formatet, det används mestadels för mänsklig läsbarhet. Vill vi kan vi skriva datan även så här:

{"device":{"hostname":"LAB01","ipv6":"FE80::903A:1C1A:E802:11E4","status":"online"}}

Men… det är inte lika snyggt och enkelt för en människa att läsa. 🙂

YAML

“YAML Ain’t Markup Language” (YAML) är ett dataserialiseringsformat vars syntax är inspirerad av XML, med ett mål att vara lättläst för människor.

Tidigare exempeldata kan skrivas som:

---
device:
  hostname: LAB01
  ipv6: FE80::903A:1C1A:E802:11E4
  status: online
...

En YAML fil öppnas med tre bindestreck och stängs med tre punkter. Datan skrivs även här som nyckel-värde-par. Datatyper för värden är heltal, strängar, boolesk eller “null” (värde utan bindning till något).

I YAML är det enklare att representera mer komplex data, så som en ordnad lista:

---
lista:
- 1
- 2
- 3
...

Någonting som är viktigt i YAML är blanksteg (indentering). Utan indentering tappar vi språkets hierarki men antalet blanksteg som vi använder har ingen betydelse; det behöver däremot vara konsekvent och skapat av mellanslagstangenten.

DEVASC: API på webben, del 1

2022-06-21T00:00:00Z

Jag vill börja detta inlägg genom att förklara 2 centrala begrepp:

“Representational State Transfer” (REST): en arkitekturstil som sätter en standard för kommunikation mellan system på webben.
“Application Program Interface” (API): definierar ett sätt för att program, system och applikationer ska kunna prata med varandra. På en väldigt hög nivå kan vi se API som en tolk för att förflytta data från en plats till en annan.

Vad är ett REST API?

Ett REST API är byggt av fyra komponenter:

“Uniform Resource Identifier” (URI)
- Identifierar en resurs och består av flera delar
- Ett exempel: https://swapi.dev/api/people/1/
  - https: definierar schemat
    - vilket protokoll som används
  - //swapi.dev definierar en “authority” komponent
    - adress för destination, består oftast av värdadress och port
  - /api/people/1/ definierar sökvägen
    - står för platsen som resursen finns på, likt exemplet kan den bestå av flera segment
- om du undrar vad skillnaderna mellan URI och URL är hade jag rekommenderat att läsa mer här: https://www.javatpoint.com/uri-vs-url
HTTP metod
- REST APIer använder de vanliga HTTP metoderna. Vilka metoder som finns tillgängliga varierar mellan olika system. De vanligaste metoderna som används är:
  - POST – skapar en ny resurs
  - GET – hämtar en resurs
  - PUT – ersätt eller uppdatera en resurs
  - PATCH – uppdatera specifika uppgifter i en resurs
  - DELETE – radera en resurs
Header
- En vanlig HTTP header används när vi jobbar med REST APIer. Den är valfri att använda och data formateras som nyckel-värde-par.
- Det finns två typer av headers:
  - Request Header – innehåller extra information som inte har med innehållet att göra, så som exempelvis autentisering
  - Entity Header – innehåller information som beskriver innehållet, så som exempelvis “content-type“
Body
- Innehållet av en förfrågan
- Denna kan vara valfri, beroende på vilken HTTP metod som används. Om vi lägger till innehåll behöver vi specificera mediatypen i en entity header (med content-type).

Alla REST APIer är inte identiska, läs alltid dokumentationen för att se hur du ska använda ett API.

I nästa del labbar vi lite för att se hur det funkar i praktiken.

DEVASC: API på webben, del 2

2022-06-21T00:00:00Z

I den tidigare delen gick vi igenom teori över REST APIer. Nu ska vi använda Python och ett HTTP bibliotek för att prata med ett API på webben.

Förutsättningar för att göra labben:

Python3.10 med “requests” biblioteket
- ett bibliotek består av färdiga moduler som underlättar utvecklingen för oss, läs mer här
En IDE (eller textredigerare) att skriva vår kod i
- jag använder Visual Studio Code

Labb

I denna labb kommer vi att anropa ett Star Wars API (SWAPI) och hämta data om Luke Skywalker. Om vi kollar på dokumentationen ser vi att SWAPI är ett öppet API (kräver ingen autentisering) och att det har ett JSON schema på sina resurser.

Vi börjar koden med att importera “requests” biblioteket:

import requests

Eftersom att vi bara ska hämta data kommer vi att använda oss av HTTP metoden “GET”. För att göra detta kommer vi använda get() metoden ur “requests”, vi sätter svaret i en variabel kallad “response” och ser även till att tolka kroppen som JSON med json() metoden:

response = requests.get('https://swapi.dev/api/people/1/').json()

Vi avslutar vårt kodstycke med att skriva ut svaret lite snyggt i terminalen (genom att hämta värdet i utvalda nyckel-värde-par formaterat i en f-sträng):

print(f"Name: {response['name']}\nHeight: {response['height']} cm\nGender: {response['gender']}")

Vår lilla kod kommer då att se ut på följande vis:

import requests

response = requests.get('https://swapi.dev/api/people/1/').json()

print(f"Name: {response['name']}\nHeight: {response['height']} cm\nGender: {response['gender']}")

Jag har valt att spara koden som en egen fil och exekverar den enligt följande, med förväntad output:

rasmus@rasmus-lnx:~/dev/routeralle/restapi$ python3 luke.py
Name: Luke Skywalker
Height: 172 cm
Gender: male

Cisco Modeling Labs: Cut to the chase

2024-12-03T00:00:00Z

For the past years I have been using EVE-NG for most of my labs. It’s been a pleasure, but I’ve always felt like something was missing when it comes to simplicity and time it takes to resolve issues from time to time. As version 2.8 of Cisco Modeling Labs (CML) featured a new free tier, I tried it and was hooked. Even though it did not bring a lot of new things to the table, it was a whole lot easier deploying and operating.

During yesterdays cyber monday sale at Cisco Learning Network Store I made a decision and bought the “Personal Plus” license. I just could not resist it at 40% off and as I am approaching more demanding studies in my CCIE EI journey, it felt like a good investment. As the free tier, it was super easy to install even tough I had some troubles in mounting and getting the files from one of the refplat ISOs the natural way via cdrom on my hypervisor. Lucky for me, transferring the file using SCP to the VM was an alternative and worked as smooth as a normal cdrom mount.

Looking forward to diving deeper in to the world of CML and connecting nodes to external services in my lab environment, such as DNAC and ISE. This will for sure be a game changer in doing larger mock labs for the CCIE.

If you have not tried CML yet, you can sign up here for the free tier, which has a 5 node limit but still allows for plenty of labbing.

Cohesion and coupling in modular programming

2025-01-27T00:00:00Z

In modular programming, cohesion and coupling are two fundamental concepts that play an important part in how you will organize your code. Understanding these concepts, and being able to balance them, forms the basis of any maintainable, efficient, and scalable software system. Let’s dive deeper into these concepts below.

Cohesion

Cohesion is about how well related different parts of a module are to each other. A module with high cohesion focuses on a single task or a single responsibility. This makes the code a lot easier to understand, test and maintain.

High cohesion: The module have a clear purpose and all parts are working together to perform a single task. As an example, one module could handle database operations, while another module manages the user interface.
Low cohesion: The module is trying to do multiple tasks at once that are not related to each other, which might lead to confusion and more difficulty maintaining the module.

An example of cohesion

import socket

class NetworkChecker:
    def is_host_reachable(self, hostname, port=80, timeout=3):
        try:
            socket.create_connection((hostname, port), timeout=timeout)
            return True
        except socket.error:
            return False


checker = NetworkChecker()
print(checker.is_host_reachable('google.com'))

The sample code above is an example of how high cohesion could look like. The reason why the class NetworkChecker is cohesive is due to it having single responsibility; the class focuses on checking network reachability only, and also being concise; it includes only the necessary logic for the specific purpose.

Before moving on to coupling, I would like to give you an idea of what low cohesion could look like. Below I have added some new rows to the previous snippet.

import socket
import time

class NetworkChecker:
    def is_host_reachable(self, hostname, port=80, timeout=3):
        try:
            socket.create_connection((hostname, port), timeout=timeout)
            return True
        except socket.error:
            return False

    def log_host_status(self, hostname, file='host_status.log'):
        status = "reachable" if self.is_host_reachable(hostname) else "unreachable"
        with open(file, 'a') as log:
            log.write(f"{time.strftime('%Y-%m-%d %H:%M:%S')} - {hostname}: {status}\n")

    def count_words(self, file_path):
        try:
            with open(file_path, 'r') as file:
                return len(file.read().split())
        except FileNotFoundError:
            return 0


checker = NetworkChecker()
print(checker.is_host_reachable('google.com'))
checker.log_host_status('google.com')
print(checker.count_words('host_status.log'))

In the sample above, you can see that there are now two new functions in the NetworkChecker class; log_host_status and count_words. This brings a lot of confusion and difficulty in maintaining code, since there is no real relation in neither functionality, clarity or requirements for testing (i.e. testing is_host_reachable requires mocking sockets, while testing count_words involves file I/O).

Coupling

Coupling is all about the dependency between different modules. The goal is to have as loose coupling as possible to make a system or application more flexible and easier to modify.

Loose coupling: The modules are quite independent from each other and communicate from module to module by utilizing well defined interfaces. This makes it easier to maintain or exchange a module without affecting the rest of the system.
Tight coupling: The modules are strongly dependent on each others internal implementations. This makes it hard to maintain a system, since a change to one module often requires change in other modules.

An example of coupling

Let’s use the same sample code that we had for cohesion but rewrite it to being loosely coupled. I will do this by implementing some abstraction.

import socket
from abc import ABC, abstractmethod

class HostReachabilityChecker(ABC):
    """
    an abstract base class defining the interface for reachability checkers
    """
    @abstractmethod
    def is_host_reachable(self, hostname, port=80, timeout=3):
        pass

class NetworkChecker(HostReachabilityChecker):
    """
    concrete implementation of HostReachabilityChecker using sockets
    """
    def is_host_reachable(self, hostname, port=80, timeout=3):
        try:
            socket.create_connection((hostname, port), timeout=timeout)
            return True
        except socket.error:
            return False

def display_host_status(checker, hostname, port=80):
    """
    function to display the reachability of a host
    """
    status = "reachable" if checker.is_host_reachable(hostname, port) else "unreachable"
    print(f"host '{hostname}' is {status} on port {port}.")


checker = NetworkChecker()
display_host_status(checker, 'google.com')

In the code above, we now have an abstract base class called HostReachabilityChecker. This is to define a common interface for checking host reachability. The abstraction allows us to decouple the display_host_status function from NetworkChecker. By relying on the interface rather than the implementation, display_host_status becomes more flexible and reusable (fulfilling the modular purpose).

If we want to change the way host reachability is checked, for example, the way host reachability is checked using some other protocol or method, then we can do this by creating a new class implementing HostReachabilityChecker without touching the existing code. In general, such separation is also good regarding testability since it is easy to mock an interface.

Connection between cohesion and coupling

A well-designed system seeks high cohesion and loose coupling. High cohesion ensures each module focuses on a single, well-defined task, whereas loose coupling will enable a module to work with others without tight coupling. Together, these principles create a codebase that is easier to maintain, extend, and adapt, fostering flexibility, scalability, and long-term reliability.

Understanding the IEEE Standard 828-2012

2025-03-05T00:00:00Z

Tonight I had a refreshment on SCM (Software Configuration Management) by reading the IEEE Std 828-2012. Software development often involves multiple contributors, complex systems, and rapidly changing requirements. In such an environment, keeping track of changes and ensuring that software artifacts remain consistent and reliable is paramount. This is where that standard comes in, to outline some best practices for SCM. The following sections will cover a shorter summary of the standard.

What is the IEEE Standard 828-2012?

The standard which is formally titled “IEEE Standard for Configuration Management in System and Software Engineering” defines the minimum requirements for creating and sustaining an effective SCM plan. It focuses on ensuring that all software-related articats (source code, documentation, design specifications, tests, etc.) are properly controlled, monitored, and traceable throughout the SDLC (Software Development Lifecycle).

The key outcome is to help teams maintain clarity over changes and mitigate risks such as version conflicts or loss of important data.

Key components

SCM planning
The standard requires a written and clearly defined SCMP (Software Configuration Management Plan). The SCMP establishes the scope, responsibilities, and tools utilized for the project SCM activities. It should specify how the software configurations are determined, track changes, who is authorized to make changes, and how records are maintained.
Configuration identification
This aspect deals with systematic labeling and organizing all software artifacts so they can be easily referenced and retrieved. Configuration identification involves:
- defining naming conventions
- versioning protocols
- establishing a baseline (snapshot at a specific point in time)
Configuration control
This ensures that only authorized and reviewed changes are incorporated into the baseline. This often involves:
- change requests and approvals to prevent unauthorized changes
- a formal process for evaluating, testing, and documenting every change
Configuration status accounting
This process tracks and reports on the status of all changes and configuration items (CIs). Through status accounting:
- teams know who changed what, when, and why
- current versions of all artifacts are known at any point
- historical data is preserved for auditing and troubleshooting
Configuration audits
Audits ensure that the software and its documentation match the established configuration records. The primary audits are functional and physical.
- Functional audits: Confirm that functionality meets the requirements
- Physical audits: Check that the documented components match the actual system components in use
Release management and delivery
This step ensures that built software, documentation, and other deliverables are packaged, labeled, and handed off securely. Proper release management involves things such as:
- maintaining a record of what has been released
- ensuring the reproducibility of releases (the ability to do a rebuild or rollback if needed)
- distributing releases with clarity around versioning and compatibility information

Why the standard matters

IEEE 828-2012 is important because it helps teams keep software changes in order and in a neat way. Without proper configuration management, software projects might be catastrophic, leading to faults, lost work, and confusion. It is valuable because of the following points

Better collaboration: It provides a structured process which allows multiple team members to work on the same project without conflicts
Fewer mistakes: With proper version control and approval processes, changes are reviewed before being implemented, reducing errors
Easy tracking: Every change is recorded, making it easier to trace issues and understand how the software evolved over time
Regulatory compliance: Many industries require strict documentation and change tracking. IEEE 828-2012 helps meet these requirements
Simplifies maintenance: When software needs updates or bug fixes, clear records help teams make changes without breaking existing features

By following this standard, organizations can create more reliable software, improve efficiency, and reduce risks in the development process.

Cisco DEVCOR 350-901 passed

2025-03-08T00:00:00Z

Yesterday I passed the Cisco DEVCOR 350-901 exam and fulfilled the DevNet Professional certification. To accompany that I today have the Credly badges to prove it.

Cisco Certified Network Professional Automation (CCNP Automation)

Cisco Certified Specialist – Automation Core

This was my first try on the exam and I must say I enjoyed it a lot, both the actual exam and the study journey. It was a really fun exam to study for and I believe it covered a lot of great topics for the modern network engineer.

Study resources used

My main study resource for the Cisco DEVCOR exam was the OCG (ISBN: 9780137370443). This book provided a structured approach to understanding key concepts and exam topics, as well as other perspectives to the world of software engineering and infrastructure automation.

In addition to the OCG, I extensively used Ciscos platform API documentation to dive deeper into automation and programmability of the different offerings. The official documentation was great for understanding how different APIs work and how to implement them effectively.

To gain hands-on experience, I leveraged the Cisco DevNet Sandbox labs. Following the exam blueprint, I practiced real-world scenarios in a lab environment, reinforcing my knowledge and improving my troubleshooting skills.

However, as learning never ends. I will end this post with a fun code-influenced line.

if exam_status == "pass":
    continue_learning()

Why post-quantum encryption matters

2025-06-18T00:00:00Z

In the world of cybersecurity, timing is indeed everything. While quantum computers capable of breaking todays encryption schemes may still be years away, the threat they pose is already here. That’s because data does not vanish after it has been transmitted, it is often stored for years. Nation-states and threat actors are already collecting encrypted traffic with the intent to decrypt it once quantum technology catches up. This strategy is known as “harvest now, decrypt later”, which turns todays secure communications into an open book tomorrow.

This looming vulnerability puts sensitive information at long-term risk. That is why the transition to post-quantum encryption is not about a theoretical exercise for the future. It is an urgent and proactive measure that needs to begin now in order to safeguard the confidentiality of data across modern networks.

Quantum computing threatens current cryptography like RSA, diffie-hellman (DH) and elliptic-curve diffie-hellman (ECDH) since these encryption schemes rely on math problems – such as factoring large numbers or solving discrete logarithms. These problems take exponential time to crack for a traditional computer, but with quantum computers using qubits instead or regular bits, they can try many possible answers at once. With Shor’s algorithm, quantum computers can quickly spot patterns in numbers – which in theory makes it possible to crack these encryptions in hours or potentially minutes. This is why we need to convert to quantum-safe encryption, which is already today supported in some network operating systems, as in Cisco IOS-XE. Let’s dive in to how we can accomplish this when setting up a VPN connection.

Cisco IOS-XE

To harden IKEv2/IPsec VPNs against future quantum threats, Cisco IOS-XE supports RFC 8784, allowing the integration of post-quantum preshared keys (also known as PPK). This setup enhances security by mixing a quantum-safe PPK into the IKEv2 key derivation process. See the example below.

There are two possible ways of generating a PPK:

Manually providing the configuration with the PPKs on responder and initiator
Using the Cisco Secure Key Integration Protocol (SKIP) for dynamic PPK provisioning with an external key source

Configuration

To summarize this blog post I thought it would be fun to show how we can accomplish this in a lab. The lab will be built on the following topology.

On both R1 and R2, let’s define the PPK manually

! R1 config
crypto ikev2 keyring PPK-KEYRING
 peer 1
  address 172.22.0.2 255.255.255.255
  ppk manual id ppk_id key ROUTERALLE

! R2 config
crypto ikev2 keyring PPK-KEYRING
 peer 1
  address 172.22.0.1 255.255.255.255
  ppk manual id ppk_id key ROUTERALLE

After this, we can normally use the keyring in our profile.

! R1 config
crypto ikev2 profile IKEv2-PROF
 match identity remote address 172.22.0.2 255.255.255.255
 authentication remote pre-shared key ROUTERALLE
 authentication local pre-shared key ROUTERALLE
 keyring ppk PPK-KEYRING

! R2 config
crypto ikev2 profile IKEv2-PROF
 match identity remote address 172.22.0.1 255.255.255.255
 authentication remote pre-shared key ROUTERALLE
 authentication local pre-shared key ROUTERALLE
 keyring ppk PPK-KEYRING

Don’t forget about a transform-set before making the IPsec profile.

crypto ipsec transform-set TS-AES256 esp-gcm 256
 mode tunnel

And then bind this information to an IPsec profile

crypto ipsec profile IPSEC-PPK-PROF
 set transform-set TS-AES256
 set ikev2-profile IKEv2-PROF

Now we can arrange the tunnel interface in our two routers.

! R1 config
interface Tunnel10
 ip address 10.1.1.1 255.255.255.252
 tunnel source GigabitEthernet1
 tunnel destination 172.22.0.2
 tunnel protection ipsec profile IPSEC-PPK-PROF

! R2 config
interface Tunnel10
 ip address 10.1.1.2 255.255.255.252
 tunnel source GigabitEthernet1
 tunnel destination 172.22.0.1
 tunnel protection ipsec profile IPSEC-PPK-PROF

Let’s verify the state of our tunnel on one of the routers by issuing a show command for viewing the security association.

R2#show crypto ikev2 sa detailed 
 IPv4 Crypto IKEv2  SA 

Tunnel-id Local                 Remote                fvrf/ivrf            Status 
1         172.22.0.2/500        172.22.0.1/500        none/none            READY  
      Encr: AES-CBC, keysize: 256, PRF: SHA512, Hash: SHA512, DH Grp:19, Auth sign: PSK, Auth verify: PSK, QR
<-- omitted output -->
      Status Description: Negotiation done
      Local id: 172.22.0.2
      Remote id: 172.22.0.1
<-- omitted output -->
      Initiator of SA : Yes
      Quantum-safe Encryption using Manual PPK
      PEER TYPE: IOS-XE
<-- omitted output -->

We can now see that the encryption used is quantum-safe by the line “Quantum-safe Encryption using Manual PPK”.

Choosing the right package manager for node applications

2026-05-26T00:00:00Z

Like many people who work with node applications, the package manager journey is shaped by whatever solved the biggest pain at the time.

I started with npm, because, that’s where everyone starts.

After npm I moved to Yarn during the period where npm installs felt slow and unreliable, especially when working on larger projects and React Native environments. Yarn brought faster installs, lockfile consistency, and generally felt more stable for day-to-day work.

At the time, it genuinely improved the developer experience.

But over the last few years, npm improved a lot, and the ecosystem changed again. That’s when I discovered pnpm. What immediately stood out with pnpm was how much more efficient it feels.

Instead of copying the same dependencies into every project, pnpm uses a content addressable store and links packages into projects, which in practice means:

less disk usage
faster installs across multiple projects
cleaner dependency management
and better enforcement of dependency correctness

The last point is surprisingly important.

The pnpm package manager exposes dependency issues that npm and Yarn sometimes let slide. Packages that rely on undeclared transitive dependencies tend to break faster under pnpm, which at first sounds annoying, but in my experience have resulted in healthier projects.

For my node applications and automation tooling, pnpm has become the default.

I still use npm when needed, and Yarn still makes sense in some ecosystems, like older React Native setups. But if I am starting a new node project today, pnpm is usually where I begin. Not because npm or Yarn are bad, but because pnpm just feels like the package manager most aligned with how modern JavaScript projects should work.

The network became code

2026-06-16T00:00:00Z

There used to be a person who knew the network, who was an artisan and for a long time the work around networks genuinely demanded artisanship. A network was a physical thing assembled for physical boxes, each configured through its own command line dialect, each subtly different from its neighbor. Expertise meant memorizing those dialects and developing an intuition for where the bodies were buried. It was skilled, valuable work. It was also completely unable to keep up with what came next.

The pressure on the previous model made it untenable. We could not scale tens of thousands of devices (physical or virtual constructs) by manually touching each and every one of them throughout their lifecycle, and the moment a “device” might live for ninety seconds before vanishing, the console cable becomes a relic. You cannot log in to something that no longer exists. The cloud finished the job when it redefined what a network even is, not a rack you can point at, but a set of abstractions you summon with an API call. And the applications riding on top stopped shipping in quarterly events and started shipping several times before lunch, leaving no room for a human to approve every change in the path. Scale, ephemerality, and pace all pushed in the same direction, and the artisan’s model had nowhere left to stand.

So the work changed in one decisive way, we stopped telling the network what to do and started telling it what to be. The artisan issued commands, just a sequence of instructions typed into a box. The modern approach declares a desired state, these networks should exist, this traffic is allowed, these routes are advertised, and a system works out how to make reality match. It sounds like a small semantic shift. It is the whole revolution. Because a description of desired state is just text, and text goes in a file, and a file goes in version control alongside the application code, and at that exact moment the network inherits everything software engineering spent decades learning.

It inherits history, where every change is recorded, attributed, and revertible. It inherits review, a second engineer reading a change before it touches anything real. It inherits testing and continuous integration that can validate a configuration, even stand up a virtual replica of the topology, before a single packet is affected. It inherits pipelines that apply changes automatically and roll them back when the signals look wrong. The 2 am fix stops being an act of heroic memory and becomes a pull request. The network is no longer a fragile thing one person understands, it is a body of code a team can reason about together.

This is where network design and software design quietly became the same discipline. A modern system holds two pictures at once, the desired state you declared and the observed state that is actually true, and runs a controller whose only job is to notice the gap and close it, continuously, without being asked. That reconciliation loop is the engine inside Kubernetes, working a cluster toward its manifests. It is the engine inside the tools that provision cloud infrastructure from declarative definitions. And it is exactly how software defined networking works, a controller programming the fabric to match intent and healing around failures as they appear. Three different layers, one identical shape. The engineer who understands the pattern in one understands it in all of them, and that transfer, not any single tool, is the real story of the modern era.

The line between “the network” and “the application” is dissolving as a result. Service meshes lift routing and traffic policy up into software that travels with the code. APIs have replaced the console cable, so an application can reshape its own connectivity at runtime as casually as it allocates memory. There is no longer a network team throwing configs over a wall to an applications team; there is one system, expressed in code, observed through shared telemetry, operated by people fluent across the layers.

None of which makes the old knowledge worthless, you cannot simply automate what you do not understand, and a clean abstraction over a system you cannot reason about is only a faster way to cause an outage. But that knowledge now lives in code and in systems thinking rather than in muscle memory and a console session. The destination is a network that disappears, not because it stopped mattering, but because it finally became programmable and self-healing enough to recede into the background, the way all good infrastructure eventually should. We spent decades unable to look away from the network. We are finally building the kind we can trust to look after itself.

Taking on a new programming language

2026-08-06T00:00:00Z

Learning a new programming language is rarely just about learning new syntax.

That came clear to me when I recently had to work on a project written in Prel. I came into it with most of my experience in Python, where I was comfortable with the language, its conventions and also the way problems are typically structured. Perl was quite unfamiliar territory, I have seen some code in the past but never really embraced and worked with it. So the biggest challenge was not simply that the language looked different.

I inherited a quite difficult and legacy codebase and at first sight, my instinct was to approach the project the same way I would approach a new Python task: identify the part that needs to be changed, understand the immediate inputs and outputs and then start improving the implementation. That approach works well when the system is familiar and the code follows conventions you already understand.

In this case, it was totally the wrong starting point.

The discomfort of unfamiliar code

Perl has a reputation for being expressive, flexible and sometimes difficult to read. In a legacy system, all three qualities can appear at once.

The code contained some unfamiliar syntax, implicit behavior, compact expressions, global state and assumptions that were not documented anywhere. Variables seemed to change meaning depending on where they were used. Subroutines had side effects that were not obvious from their names. Some parts looked unnecessarily complicated, while others appeared simple but were connected to behavior elsewhere in the application.

My initial reaction was to translate everything mentally to a language that I am comfortable with, like Python.

I kept asking myself how I would write the same logic using dictionaries, functions, classes, exceptions or some clearer control flow. That helped me understand individual lines but it also created a dangerous bias. I started judging the Perl code according to Pythonic ways of working before I fully understood why it had been written that way.

Different languages encourage different styles. More importantly, old systems develop their own internal logic over time. A piece of code may look strange because it is poorly written but it may also look strange because it protects against a production issue that occurred years ago.

Without context, the two situations can become difficult to distinguish from one another.

Reading before changing

I believe that the most important lesson from the project was very simple. Read the code before trying to change the code. It can sound very obvious but in practice it requires discipline.

Reading the code is not the same as scanning until you find the line you want to edit. It means tracing the data through the system, identifying where the values originate, understanding which subroutines that mutate state, and also looking for dependencies that are not visible from the immediate call path.

I had to slow down in my work. Instead of immediately rewriting unfamiliar sections, I started documenting what I could prove about the system. I followed variables from input to output. I searched every place a subroutine was called. I compared similar code paths. I inspected logs and existing tests. Where tests did not exist, I created small experiments to verify how the code behaved.

The goal was not to understand all of Perl. It was to understand this particular system well enough to make a safe change. That shift made a significant difference.

Once I stopped treating the codebase as something that needed to be cleaned up immediately, I began to see its structure. Patterns started emerging. Some confusing decisions were still questionable however, but others turned out to be deliberate. Code that initially looked redundant was handling edge cases. Values that appeared unused were consumed indirectly. Certain conventions were inconsistent by modern standards but consistent within the application itself.

The code became less mysterious once I learned to observe it on its own terms.

Legacy code might be a communication problem

Working on this project reminded me that working with legacy code is not only a technical problem. It is a communication problem across time.

The original developers made decisions based on requirements, constraints, incidents and some deadlines that I could no longer see. The code was their remaining explanation, even though it was incomplete and missing documentation. My job was to reconstruct enough of that missing context to change the system in a responsible manner.

It is easy to enter an unfamiliar codebase and immediately notice everything I myself would do differently. It is much hared to recognize that our preferred solutions is shaped by our own experience, tools and assumptions.

Modernizing code can be valuable. Refactoring can reduce risk and make future work on the project easier. But changing code before understanding its behavior can turn an ugly but functioning system into a clean looking failure.

I believe that a few questions that will follow along to the next legacy project I work with is:

What does the code currently do?
Why might it have been written this way?
What is the smallest safe change that solves the actual problem?

Only after answering those questions should any writing begin.

Growth that happens outside of the comfort zone

Most developers have a language in which they feel at home. For me, that language is Python. Its readability, ecosystem and overall development experience align well with how I like to solve my problems. But comfort can also create blind spots.

Working in Perl forced me to operate without many of my usual instincts. I had to learn new conventions, question familiar assumptions and last but not least, accept that my first interpretation of the code was often incomplete. That discomfort was valuable.

Learning a new programming language is not only about adding another technology to the CV. It is an opportunity to examine the habits we have developed in our primary language. It shows us which ideas a fundamental and which are simply conventions we have become accustomed to.

The Perl project did not make me abandon my preference in Python. It made me a better developer in general by strengthening some of my weaknesses. It is hard to change both familiar and unfamiliar code unless you can prove that you understand it.

Goodbye WordPress: rebuilding the blog

2026-08-10T00:00:00Z

After several years of running this blog on WordPress, I have now replaced it with a static site built with Eleventy. The two big reasons were hosting costs and to have something that feels more like me.

If you have visited the site before, you will notice that things look quite different around here. That is very much the point.

Why leave WordPress

WordPress has served me well and I have nothing bad to say about it as a platform. But for a small blog like this one, it started to feel like driving a truck to the mailbox.

The site was running on a Lightsail instance in AWS, which meant a virtual machine humming along all day, every day, just to serve a handful of static pages to the sites visitors. That is a few dollars every month for compute that mostly sits idle. On top of that comes the part nobody talks about when they recommend WordPress: the maintenance. Core updates, plugin updates, PHP versions, backups and the constant background noise of bots probing wp-login.php. None of it is difficult, but it is a recurring chore for the site. Now that I want to get into writing more frequently, I would like for my focus to stay on that and not putting effort into the negative sides that WordPress comes with.

A blog is text. Text does not need a database and an application server. It needs a place to live and a way to get there.

Getting my own style

The second reason was more personal. With WordPress you pick a theme, and no matter how much you adjust it, the site always ends up looking like, well, a WordPress theme. Mine never really felt like mine.

This time I designed the site from scratch. It is heavily inspired by the terminal, which felt fitting for a blog that is mostly about networking and automation. Monospace fonts in the navigation, a blinking cursor in the wordmark and headings that look like markdown. There is a light and a dark mode that follows your system preference, with a small toggle if you disagree with your operating system. The whole stylesheet is one hand-written CSS file. No frameworks, no build pipeline for the styling, nothing to update next year. It is a simple design, but it is my simple design.

The new stack

The site is built with Eleventy, a static site generator that gets out of the way. Posts are plain markdown files in a git repository. The templates are a handful of Nunjucks files. That is more or less it.

Hosting is an S3 bucket behind CloudFront, with a certificate from ACM. Deployment happens through GitHub Actions: every push to the main branch builds the site and syncs it to the bucket using OIDC, so there are no long-lived AWS keys stored anywhere. Publishing a post is now as simple as:

git add posts/2026-08-10-my-new-post.md
git commit -m "Add new post"
git push

About a minute later it is live. Drafts are just a draft: true line in the frontmatter, visible locally but excluded from the production build.

What it costs now

The old setup was a Lightsail instance billed every hour of every month. The new one is S3 storage measured in cents, CloudFront traffic that for a site this size stays within very little money, and a certificate that costs nothing. The GitHub Actions minutes are within the free tier. For a personal blog, the hosting bill has essentially gone from a subscription to a rounding error, lol.

And since the whole site is a git repository, the backup strategy is the same as for any other code I write.

alias publish="git push"