Frameworks & Tools on Backend Engineering Strategy Tools

Backstage

Mon, 08 Jun 2026 00:00:00 +0000

Backstage is an open-source framework for building Internal Developer Portals (IDPs). Created by Spotify, donated to the CNCF in 2022. The core idea: instead of every team maintaining their own scattered documentation, dashboards, and service scaffolding, you consolidate it into one place that the whole organisation uses.

You deploy your own instance. Backstage is not a SaaS — it is a framework you run and extend. The investment is real, but so is the payoff once adoption reaches critical mass.

Core plugins

Backstage ships with a small core and a large plugin ecosystem. The four foundational pieces:

Software Catalog

The catalog is a registry of everything your organisation owns: services, libraries, websites, pipelines, ML models, databases. Each entity is described by a catalog-info.yaml file committed alongside the code it describes.

# catalog-info.yaml — lives in the repo root
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
 name: payments-service
 description: Handles payment processing
 tags:
 - java
 - payments
 annotations:
 github.com/project-slug: myorg/payments-service
 backstage.io/techdocs-ref: dir:.
spec:
 type: service
 lifecycle: production
 owner: payments-team
 system: commerce

Backstage imports entities from Locations — typically Git repositories. The catalog refreshes on a schedule and stays in sync with the catalog-info.yaml files across your repos.

Scaffolder (Software Templates)

The Scaffolder lets platform teams publish templates for creating new projects. Developers pick a template, fill in a form, and Backstage creates the repo, applies the template, opens a PR — whatever the template defines.

Templates are defined in YAML and use ${{ parameters.name }} substitution. Actions are either built-in (publish:github, fetch:template, catalog:register) or custom.

apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
 name: go-service
 title: Go Microservice
spec:
 owner: platform-team
 type: service
 parameters:
 - title: Service details
 properties:
 name:
 type: string
 title: Service name
 steps:
 - id: fetch
 name: Fetch template
 action: fetch:template
 input:
 url: ./skeleton
 values:
 name: ${{ parameters.name }}
 - id: publish
 name: Create repo
 action: publish:github
 input:
 repoUrl: github.com?repo=${{ parameters.name }}&owner=myorg

TechDocs

TechDocs renders Markdown documentation from repos as browsable pages inside Backstage. It uses MkDocs under the hood. Annotate the entity with backstage.io/techdocs-ref: dir:. and place a mkdocs.yml in the repo root.

# mkdocs.yml
site_name: Payments Service
nav:
 - Home: index.md
 - Architecture: architecture.md
docs_dir: docs
plugins:
 - techdocs-core

Docs are either built at read-time (dev mode) or pre-built and stored in object storage (S3/GCS) for production. Pre-built is the right default for production — it separates the build from the render and avoids build overhead at page load.

Search

Full-text search across the catalog, TechDocs, and any plugin that contributes a search collator. Powered by Lunr (local) or Elasticsearch for production deployments.

Entity model

Kind	Represents
`Component`	A deployable unit: service, website, library
`API`	An interface exposed by a Component
`Resource`	Infrastructure a Component depends on (DB, queue)
`System`	A collection of related Components and Resources
`Domain`	A business domain grouping Systems
`Group`	A team or organisational unit
`User`	An individual
`Template`	A Scaffolder template
`Location`	A pointer to where entities are defined

The relationships (providesApis, consumesApis, dependsOn, partOf) are what make the catalog navigable — you can trace dependencies across services and see who owns what.

Architecture

Browser
 └─ Backstage frontend (React, @backstage/core-*)
 └─ Backstage backend (Node.js, Express)
 ├─ Catalog backend — entity processing pipeline
 ├─ Scaffolder backend — template execution
 ├─ TechDocs backend — doc building/serving
 ├─ Auth backend — OAuth providers
 └─ PostgreSQL — persistent state

The backend is a Node.js monolith you extend with plugins. Each plugin typically registers API routes and a database schema. The frontend is a React SPA — plugins register pages, sidebar entries, and entity tab content.

Getting started

npx @backstage/create-app@latest
cd my-backstage-app
yarn dev # starts both frontend (:3000) and backend (:7007)

This scaffolds a working app with the catalog, scaffolder, and TechDocs already wired up. SQLite is the default database for local dev; switch to PostgreSQL before running anything that matters.

Helm chart (production)

helm repo add backstage https://backstage.github.io/charts
helm install backstage backstage/backstage -f values.yaml

The chart expects an app-config.yaml mounted as a ConfigMap and PostgreSQL credentials in a Secret.

app-config.yaml

The main config file. Controls database, auth providers, integrations, and plugin configuration. Environment-specific overrides go in app-config.production.yaml.

backend:
 baseUrl: https://backstage.example.com
 database:
 client: pg
 connection:
 host: ${POSTGRES_HOST}
 user: ${POSTGRES_USER}
 password: ${POSTGRES_PASSWORD}

integrations:
 github:
 - host: github.com
 token: ${GITHUB_TOKEN}

catalog:
 locations:
 - type: url
 target: https://github.com/myorg/catalog/blob/main/all.yaml

auth:
 providers:
 github:
 development:
 clientId: ${AUTH_GITHUB_CLIENT_ID}
 clientSecret: ${AUTH_GITHUB_CLIENT_SECRET}

Plugin ecosystem

Backstage has 200+ community plugins. Common ones:

Plugin	What it adds
`kubernetes`	Live cluster view scoped to an entity
`github-actions`	CI/CD run status on entity pages
`pagerduty`	On-call and incident status per service
`sonarqube`	Code quality metrics per component
`cost-insights`	Cloud cost breakdown by team
`lighthouse`	Web performance audits
`argo-cd`	ArgoCD sync status on entity pages

Plugins are npm packages. Install, register in packages/app/src/App.tsx (frontend) and packages/backend/src/index.ts (backend).

Adoption pattern

The catalog only becomes useful when it is comprehensive. The typical path:

Import existing services by pointing the catalog at repos that have catalog-info.yaml
Add a bulk-importer location (a catalog-info.yaml that lists other locations) to bootstrap coverage
Enforce catalog-info.yaml in new repos via the Scaffolder — templates create it automatically
Build TechDocs incrementally — services that already have docs/ directories are easy wins
Add the Kubernetes plugin once catalog ownership is clean — it ties live cluster state to catalog entities

Resources

Backstage.io — official docs
Backstage GitHub
Backstage Helm chart
CNCF project page
Plugin marketplace
ADR-002: Backstage Software Catalog — explains the entity model design

Blender Python — Procedural Mesh for 3D Printing

Tue, 02 Jun 2026 00:00:00 +0000

Write a Python script that builds geometry programmatically using Blender’s bpy API, then export as STL. No manual modelling — the script is the source of truth, re-running it regenerates everything.

This pattern is useful when you have a family of similar parts (different sizes, repeated structures, parametric variations) or when the geometry is defined by rules rather than artistic decisions.

When to use this vs. alternatives

	Blender Python	OpenSCAD	CadQuery
Booleans, extrude, modifiers	✓ built-in	✓ CSG only	limited
Sculpt / organic shapes	✓	✗	✗
Parametric constraints	manual	manual	✓ strong
Python ecosystem	✓ full stdlib	✗ own language	✓
Interactive viewport preview	✓	✗	✗
Export to STL	✓ one call	✓	✓

For repetitive mechanical geometry with booleans (holes, sockets, cutouts), Blender Python is the fastest path if you already know Python. The interactive viewport lets you catch geometry problems before exporting.

Core pattern

Every script follows the same structure:

import bpy, bmesh, math, os

# 1. Create a primitive — it becomes bpy.context.object
bpy.ops.mesh.primitive_cylinder_add(vertices=64, radius=5, depth=3)
obj = bpy.context.object

# 2. Edit vertices directly via bmesh
bpy.ops.object.mode_set(mode='EDIT')
bm = bmesh.from_edit_mesh(obj.data)
for v in bm.verts:
 if v.co.z > 0:
 v.co.x *= 0.9 # taper the top
bmesh.update_edit_mesh(obj.data)
bpy.ops.object.mode_set(mode='OBJECT')

# 3. Boolean modifier to cut a hole
bpy.ops.mesh.primitive_cylinder_add(radius=2, depth=3.2)
cutter = bpy.context.object
mod = obj.modifiers.new("Hole", 'BOOLEAN')
mod.object = cutter
mod.operation = 'DIFFERENCE'
bpy.context.view_layer.objects.active = obj
bpy.ops.object.modifier_apply(modifier=mod.name)
bpy.data.objects.remove(cutter, do_unlink=True)

# 4. Export
bpy.ops.object.select_all(action='DESELECT')
obj.select_set(True)
bpy.ops.wm.stl_export(filepath="/tmp/part.stl", export_selected_objects=True)

Build complexity by wrapping each operation in a function, then calling it in a loop over a size or parameter list.

Running the script

Open Blender → switch to the Scripting workspace
Click New or Open to load your .py file
Click Run Script (▶) or press Alt + P

Output and errors appear in the system console (Window → Toggle System Console on Windows, or launch Blender from a terminal on macOS/Linux).

Key API surface

Primitives

bpy.ops.mesh.primitive_cylinder_add(vertices=32, radius=r, depth=h)
bpy.ops.mesh.primitive_cube_add(size=s)
bpy.ops.mesh.primitive_plane_add(size=s)

All primitives land at the world origin and become bpy.context.object.

Transforms

obj.scale = (sx, sy, sz)
obj.location = (x, y, z)
obj.rotation_euler = (rx, ry, rz) # radians
bpy.ops.object.transform_apply(scale=True, location=False, rotation=False)

Apply transforms before any bmesh edits — otherwise vertex coordinates are in local (pre-scale) space, and your edit positions won’t match world coordinates.

bmesh (direct vertex / edge / face editing)

bpy.ops.object.mode_set(mode='EDIT')
bm = bmesh.from_edit_mesh(obj.data)
for v in bm.verts:
 if v.co.z > 0:
 v.co.x *= 0.9
bmesh.update_edit_mesh(obj.data)
bpy.ops.object.mode_set(mode='OBJECT')

Boolean modifiers

mod = target.modifiers.new("Name", 'BOOLEAN')
mod.object = cutter
mod.operation = 'DIFFERENCE' # or UNION or INTERSECT
mod.solver = 'EXACT' # more reliable than FAST for tight geometry
bpy.context.view_layer.objects.active = target
bpy.ops.object.modifier_apply(modifier=mod.name)
bpy.data.objects.remove(cutter, do_unlink=True)

Apply and remove the cutter immediately — leaving stale cutter objects causes confusion on subsequent runs.

Joining objects (single boolean cut for a grid of holes)

Rather than applying one boolean per hole, join all cutters first:

for obj in cyl_objects:
 obj.select_set(True)
bpy.context.view_layer.objects.active = cyl_objects[0]
bpy.ops.object.join()
cutter = bpy.context.active_object
# now do one boolean cut on the plate

One boolean operation is faster and produces cleaner topology than N serial cuts.

STL export (Blender 4.x / 5.x)

bpy.ops.wm.stl_export(filepath="/abs/path/part.stl", export_selected_objects=True)

Collections (organising multi-part output)

col = bpy.data.collections.new("Round Bases")
bpy.context.scene.collection.children.link(col)
for c in obj.users_collection:
 c.objects.unlink(obj)
col.objects.link(obj)

Parametric families

The main loop pattern — build one function that takes dimensions, call it for each size:

SIZES = [10, 15, 20, 25]

for w in SIZES:
 obj = make_clip(width=w)
 obj.name = f"clip_{w}mm"
 bpy.ops.object.select_all(action='DESELECT')
 obj.select_set(True)
 bpy.ops.wm.stl_export(
 filepath=f"/output/clip_{w}mm.stl",
 export_selected_objects=True
 )

Put all tuneable values at the top of the file in a # CONFIG block. This makes the script easy to hand to Claude and say “change the hole diameter to 7mm and add two more rows.”

Clearing the scene before a run

Add this at the top when iterating interactively — otherwise re-running doubles the objects:

bpy.ops.object.select_all(action='SELECT')
bpy.ops.object.delete()
for block in bpy.data.meshes:
 bpy.data.meshes.remove(block)

Viewport layout before export

Spread objects out so you can visually review them before committing to an export:

xoff = 0
for obj, w in zip(objects, widths):
 obj.location.x = xoff
 xoff += w + 5

For print batches, sort largest-first and pack into rows within your bed dimensions (shelf bin-packing against PLATE_W × PLATE_H).

Working with Claude

The config-block pattern pairs well with LLM iteration. Because all tuneable values sit in one place and each operation is a named function, you can describe changes in plain language:

“Change HOLE_DIAM to 6 and add a third text line below line 2” — Claude edits two constants and adds a make_line() call.
“The holes in rows 2 and 3 need 3mm more clearance from the edge” — Claude adjusts x_origin offset computation.
“Add a chamfer around the perimeter of the top face” — Claude adds a bmesh loop and inset operation.

The workflow is: run → look at viewport → describe the problem → apply updated script → repeat. Iteration is fast because the viewport gives immediate visual feedback and the script regenerates from scratch each run.

Limitations

Booleans are fragile on non-manifold geometry. If a cutter face is coplanar with the target, or vertices are nearly coincident, Blender’s solver can produce garbage. Add a small bleed (0.5–1 mm) so cutters fully penetrate surfaces.

No parametric constraints. Unlike CadQuery, there is no “keep this face parallel to that face” system. Dimension changes cascade manually. This is manageable when the config block is the only place numbers live.

Script state accumulates. Re-running in an existing scene doubles the objects. Clear the scene first (see above) or check for existing objects by name before creating.

Garage — Scripted Parts — hole box and other physical builds using this approach
Rack Support Brace — step-by-step: script → renders → headless → CI/CD

Code Quality & Architecture Analysis

Mon, 01 Jan 2024 00:00:00 +0000

Static analysis catches bugs and code smells before they reach production. Architecture analysis catches structural decay before the codebase becomes unmaintainable. SonarQube does the former; Structure101 does the latter.

SonarQube

A code quality and security platform. SonarQube runs static analysis on your codebase and reports bugs, code smells, security hotspots, and test coverage in a web dashboard. It supports 30+ languages; the Java and Kotlin analysis is particularly deep. Integrates into CI pipelines via the SonarScanner — a quality gate can fail the build if new code introduces issues above a configured threshold.

# Run analysis (from project root, after configuring sonar-project.properties)
sonar-scanner \
 -Dsonar.projectKey=my-project \
 -Dsonar.sources=src/main \
 -Dsonar.tests=src/test \
 -Dsonar.host.url=https://sonarqube.example.com \
 -Dsonar.token=$SONAR_TOKEN

Quality gates define the conditions a project must meet — for example: no new critical bugs, test coverage on new code ≥ 80%, no new security hotspots unreviewed. A gate failure blocks the PR merge or CI pipeline. The built-in “Sonar Way” gate is a sensible default; most teams customise it over time.

SonarQube Community Edition is free and covers the core analysis features. Enterprise Edition adds branch analysis, portfolio views, and security reports.

Structure101

An architecture analysis tool for Java projects. Structure101 visualises the dependency structure of a codebase as a layered graph and identifies violations — circular dependencies between packages, classes depending on layers they shouldn’t reach, packages with too many inbound dependencies. It is particularly useful for large, long-lived Java codebases where architectural boundaries have eroded over time.

The key report is the tangle metric: a tangle is a group of packages with circular dependencies, and the tangle percentage measures how much of the codebase is affected. A clean architecture has zero tangles. Structure101 shows exactly which dependencies create each tangle, making it possible to systematically break them.

It integrates with build systems (Maven, Gradle) to enforce architecture rules in CI — build fails if the tangle percentage exceeds a threshold, or if a dependency violates a defined layering rule.

Resources

Docker & OCI

Mon, 01 Jan 2024 00:00:00 +0000

Docker packages applications and their dependencies into portable, reproducible units called containers. Unlike virtual machines, containers share the host kernel — they’re isolated processes, not emulated hardware. This makes them fast to start, light on resources, and consistent across environments: the same image runs on a developer’s laptop, in CI, and in production.

Docker popularised containers, but the underlying standard is now open. The OCI (Open Container Initiative) defines three specifications:

Image spec — the format of a container image: layers, config, manifest
Runtime spec — how a container is run: namespaces, cgroups, lifecycle
Distribution spec — how images are pushed and pulled from registries

Any tool that produces an OCI image can run on any OCI-compliant runtime. Docker is one implementation. It is still the most natural entry point and the docker CLI remains the most familiar interface, but it is worth knowing that the ecosystem is broader than Docker Inc.

OCI images and containers

An image is a read-only, layered filesystem snapshot built from a Dockerfile — each layer is a diff on top of the previous one. A container is a running instance of an image — an isolated process with its own filesystem, network interface, and process space, sharing the host kernel.

docker build -t myapp:1.0 . # build OCI image from Dockerfile
docker run -p 8080:8080 myapp:1.0 # start container
docker ps # list running containers
docker exec -it <id> bash # shell into a running container

Images are stored in registries — Docker Hub, GitHub Container Registry, ECR, Nexus. All speak the OCI distribution spec, so images built with any tool push and pull the same way.

Dockerfile

The Dockerfile defines how an image is built — each instruction adds a layer:

FROM golang:1.22-alpine AS build
WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN go build -o /app/server .

FROM alpine:3.19
COPY --from=build /app/server /server
EXPOSE 8080
ENTRYPOINT ["/server"]

Multi-stage builds keep the final image lean: the first stage compiles using the full toolchain, the second copies only the binary. No compiler, no source, no build cache in the image you ship.

Order matters for layer caching — put things that change rarely (dependency downloads) before things that change often (source code). A cache miss invalidates all subsequent layers.

Volumes and bind mounts

Containers have ephemeral filesystems — anything written inside is lost when the container stops. Persist data with volumes:

docker volume create pgdata
docker run -v pgdata:/var/lib/postgresql/data postgres:16

For local development, bind mounts map a host directory into the container:

docker run -v $(pwd):/app -w /app node:20 npm test

Networking

Containers on the same Docker network can reach each other by name. Docker Compose creates a default network automatically; named networks can be created explicitly:

docker network create backend
docker run --network backend --name db postgres:16
docker run --network backend myapp # can reach 'db' by hostname

Podman

Podman is a drop-in Docker replacement that runs without a daemon and without root. The CLI is intentionally compatible:

alias docker=podman # usually just works

Rootless containers mean a compromised container process cannot escalate to host root. Daemonless means no long-running background service with broad system access. On RHEL and Fedora, Podman is the default. For CI environments and security-conscious setups it is the better choice.

Podman also supports pods — groups of containers sharing a network namespace, mirroring the Kubernetes pod model. Useful for local development that needs to mirror how things will run in the cluster.

Buildah

Buildah builds OCI images without a Docker daemon. It can build from a Dockerfile or construct images programmatically using shell commands — useful in CI pipelines where running a privileged Docker daemon is undesirable:

buildah bud -t myapp:1.0 . # build from Dockerfile
buildah push myapp:1.0 registry/myapp:1.0

Buildah and Podman share the same underlying storage, so images built with Buildah are immediately available to Podman.

Docker Compose

Compose manages multi-container applications defined in compose.yml:

services:
 app:
 build: .
 ports:
 - "8080:8080"
 environment:
 DATABASE_URL: postgres://app:secret@db/appdb
 depends_on:
 - db

 db:
 image: postgres:16
 volumes:
 - pgdata:/var/lib/postgresql/data
 environment:
 POSTGRES_PASSWORD: secret

volumes:
 pgdata:

docker compose up -d # start in background
docker compose logs -f # stream logs
docker compose down # stop and remove containers

Compose is useful for local development environments. It is a shame it exists as a separate abstraction — it taught people to think in multi-container terms without teaching them Kubernetes, and then left them with a gap to cross when they needed to go to production. That said, it is practical for what it does and is not going away.

For production orchestration, see Kubernetes.

Skopeo

Skopeo works with OCI images directly — copy, inspect, and convert — without pulling them to local storage. Useful in pipelines and for auditing registries:

# Inspect an image without pulling it
skopeo inspect docker://registry.example.com/myapp:1.0

# Copy between registries without touching local disk
skopeo copy docker://source-registry/myapp:1.0 docker://dest-registry/myapp:1.0

# Copy to a local OCI layout
skopeo copy docker://myapp:1.0 oci:myapp-local:1.0

skopeo inspect is particularly useful for checking image metadata, digest, and labels in CI before deciding whether to promote an image.

ORAS

ORAS (OCI Registry As Storage) pushes and pulls arbitrary artifacts to OCI registries — not just container images. Helm charts, SBOMs, attestations, Terraform modules, binary releases — anything can be stored in a registry that speaks OCI distribution spec:

# Push a file as an OCI artifact
oras push registry.example.com/myapp-sbom:1.0 sbom.json:application/spdx+json

# Pull it back
oras pull registry.example.com/myapp-sbom:1.0

This matters because it means a single registry can become the distribution mechanism for the entire software supply chain — image, SBOM, signature, attestation — all with the same access controls and audit trail.

Useful practices

Use specific image tags (postgres:16.2, not postgres:latest) — latest changes under you
Reference images by digest in production (myapp@sha256:abc123) — tags are mutable, digests are not
Run as a non-root user: USER appuser in the Dockerfile
Add a .dockerignore to exclude .git, node_modules, build artefacts from the build context
Keep images small — large images are slow to push, pull, and scan

Resources

Elasticsearch & Kibana

Mon, 01 Jan 2024 00:00:00 +0000

Elasticsearch is a distributed search and analytics engine built on Apache Lucene. Kibana is its web UI for querying, visualising, and exploring the data stored in Elasticsearch. Together they form the search and analysis layer of the ELK stack — typically with Logstash or Beats collecting and shipping data into Elasticsearch, and Kibana on top for humans to interact with it.

Elasticsearch

A document store where every document is JSON and every field is indexed by default. Queries are also JSON, using a rich query DSL that supports full-text search, structured filters, aggregations, and geospatial queries. Elasticsearch is horizontally scalable — an index is split into shards, shards are distributed across nodes, and replicas provide redundancy. Adding nodes increases both capacity and query throughput.

# Index a document
POST /logs/_doc
{
 "timestamp": "2026-06-04T12:00:00Z",
 "level": "error",
 "service": "api",
 "message": "connection refused"
}

# Search with filter
GET /logs/_search
{
 "query": {
 "bool": {
 "filter": [
 { "term": { "level": "error" } },
 { "term": { "service": "api" } }
 ]
 }
 }
}

At scale, index lifecycle management (ILM) policies handle the hot-warm-cold tiering automatically — recent indices stay on fast nodes, older indices roll to cheaper storage, and expired indices are deleted.

Kibana

The interface to Elasticsearch. Kibana’s core is Discover — a time-series log explorer with free-text search and field filtering — and Dashboards — composable visualisations (time series, bar charts, pie charts, data tables, maps) that query Elasticsearch directly. For log aggregation and observability use cases, a typical workflow is: ship logs into Elasticsearch via Filebeat or Logstash, explore them in Discover, build dashboards for the signals that matter, set up alerting rules on those patterns.

Kibana also hosts the Elastic APM UI (application performance monitoring), the SIEM app (security event correlation), and the Lens visual editor for building dashboards without writing aggregation queries by hand.

ELK vs the Grafana stack

The Grafana stack (Loki + Prometheus + Grafana) has become the common alternative for cloud-native environments. The key difference: Loki indexes only log metadata (labels), not the full log content — it is cheaper to run and query at scale, but full-text search across log bodies is slower. Elasticsearch indexes everything and full-text search is fast, but the storage and memory cost is significantly higher. For log volumes in the hundreds of GB/day and above, the operational cost of Elasticsearch becomes the dominant factor. For environments that need fast full-text search across structured and unstructured data — logs, documents, events — Elasticsearch earns its cost.

Resources

IntelliJ IDEA

Mon, 01 Jan 2024 00:00:00 +0000

IntelliJ IDEA is JetBrains’ Java and Kotlin IDE. It has the deepest language understanding of any Java IDE — code completion that reasons about types across the entire project, refactoring that updates all call sites, a debugger with expression evaluation, and a profiler integrated into the same window. The free Community Edition covers Java, Kotlin, Groovy, and Scala. The paid Ultimate Edition adds frameworks (Spring, Quarkus, Micronaut), database tools, HTTP client, and built-in support for web technologies.

Key capabilities

Refactoring — rename a class and every reference in every file updates. Extract method, inline variable, move class to a different package, change method signature — all with full project-wide impact analysis before execution.

Navigation — Cmd+Click goes to declaration, Cmd+B shows all usages, Cmd+E opens recent files, Cmd+Shift+F searches across the entire project. In a large codebase, knowing where things are called from matters more than reading the code.

Inspections — real-time static analysis flags potential bugs, code style violations, and anti-patterns as you type, not at build time.

Debugger — set breakpoints, step through code, evaluate arbitrary expressions in the current scope, watch variables, set conditional breakpoints. Remote debugging attaches to a running JVM with a single click.

Plugins

The plugin ecosystem extends IDEA significantly. Notable ones:

IdeaVim — vim key bindings throughout the editor
Kubernetes — YAML editing with schema validation and cluster connectivity
Database tools (Ultimate) — query databases from within the IDE

Remote development

IDEA supports JetBrains Gateway for remote development — the IDE UI runs locally but the indexing and execution happen on a remote machine or container. Useful for developing against large codebases on powerful remote hardware.

Resources

K9s & Lens

Mon, 01 Jan 2024 00:00:00 +0000

You run everything with kubectl. Get pods, describe, logs, exec, delete, apply — fifty times a day across five namespaces. It works, but every command is a context switch: type, wait, read, type again. -n namespace on every single invocation.

So you use K9s. A terminal UI that shows your entire cluster in one view. Switch namespaces and clusters in a keystroke, tail logs in real time, exec into a pod without constructing the command — everything you reach for in kubectl, but without the friction.

K9s

K9s is a TUI (terminal UI) for Kubernetes. It stays in your terminal, updates live, and is keyboard-driven throughout.

brew install derailed/k9s/k9s
k9s # connect to current context
k9s --context prod # specific context
k9s -n monitoring # start in a specific namespace

Key	Action
`:pod`	Jump to pods view
`:deploy`	Deployments
`:svc`	Services
`:ns`	Switch namespace
`/`	Filter/search
`l`	Logs
`e`	Edit resource YAML
`d`	Describe
`s`	Shell into pod
`ctrl-d`	Delete
`?`	Help / full keybinding list

Most resource types are reachable by typing : followed by the resource name — :configmap, :secret, :ingress, :pvc, and so on.

Why TUI over GUI

K9s lives in the terminal alongside your other tools. No window switching, works over SSH, starts instantly, and the keyboard-driven workflow is faster once it is in muscle memory. For day-to-day cluster work it is the right default.

Lens

Lens is a desktop GUI for Kubernetes — a full IDE-style interface with a visual cluster overview, resource browsing, metrics charts, log streaming, and terminal access built in.

It is the better choice when you need to onboard someone who is not yet comfortable with the terminal, or when you want a visual overview to share with a non-technical stakeholder. For engineers doing operational work all day, K9s is faster.

Worth noting: Lens has moved toward a commercial model (Lens Desktop Pro). OpenLens is the open-source build of the same codebase, without the account requirement.

kubectx / kubens

If K9s is more than you need and you just want to stop typing --context and -n on every command, kubectx and kubens solve exactly that:

kubectx # list contexts
kubectx prod # switch to prod context
kubectx - # switch back to previous context

kubens # list namespaces
kubens monitoring # switch default namespace

No TUI, no GUI — just fast context and namespace switching that persists for the rest of your terminal session. Install alongside K9s; they complement each other.

brew install kubectx

Resources

K9s documentation
K9s GitHub
Lens
OpenLens — open-source Lens build
kubectx/kubens — fast context and namespace switching

Nexus Repository

Mon, 01 Jan 2024 00:00:00 +0000

Sonatype Nexus Repository Manager is a universal artifact repository. It stores and serves build artifacts — Maven JARs, npm packages, Docker images, Helm charts, PyPI packages, raw binaries — from a single platform. It operates in three modes: hosted (your own artifacts), proxy (a local mirror of an upstream registry), and group (a virtual repository that aggregates hosted and proxy repos behind one URL).

Why it exists

Two problems: you want a private registry for internal artifacts (container images, internal libraries), and you want to cache upstream registries to reduce build times, avoid rate limits, and insulate builds from upstream outages. Nexus solves both. Point your build tools at Nexus; Nexus fetches from upstream on first request and caches, or serves from your hosted repos.

Repository types

# Maven proxy — caches Maven Central
https://nexus.example.com/repository/maven-central/

# Maven hosted — your internal JARs
https://nexus.example.com/repository/maven-releases/
https://nexus.example.com/repository/maven-snapshots/

# Docker hosted — your container images
https://nexus.example.com/repository/docker-hosted/

# npm proxy — caches registry.npmjs.org
https://nexus.example.com/repository/npm-proxy/

Docker integration

Nexus can expose a hosted Docker registry on a dedicated port. Configure the Docker daemon to trust the registry, then push and pull normally:

docker login nexus.example.com:8082
docker tag myimage:latest nexus.example.com:8082/myimage:latest
docker push nexus.example.com:8082/myimage:latest

Maven integration

Point Maven at Nexus by configuring settings.xml to use the Nexus group repository as a mirror:

<mirrors>
 <mirror>
 <id>nexus</id>
 <mirrorOf>*</mirrorOf>
 <url>https://nexus.example.com/repository/maven-public/</url>
 </mirror>
</mirrors>

All dependency resolution goes through Nexus. Cached. Air-gapped builds are possible by pre-populating the cache.

Resources

NGINX

Mon, 01 Jan 2024 00:00:00 +0000

NGINX is a high-performance web server and reverse proxy built around an event-driven, non-blocking architecture. Where Apache spawns a thread per connection, NGINX handles thousands of concurrent connections from a small, fixed number of worker processes — making it well-suited to acting as the entry point for modern distributed systems.

Server blocks

NGINX configuration is structured around server blocks (analogous to Apache’s VirtualHost). Each block defines how to handle requests for a given hostname or port:

server {
 listen 80;
 server_name example.com;

 location / {
 root /var/www/html;
 index index.html;
 }
}

Multiple server blocks in a single NGINX instance handle traffic for different domains — NGINX selects the block by matching the Host header against server_name.

Reverse proxy

The primary use case in infrastructure work: NGINX sits in front of application servers and forwards requests to them. The application never needs to be exposed directly.

server {
 listen 80;
 server_name api.example.com;

 location / {
 proxy_pass http://127.0.0.1:8080;
 proxy_set_header Host $host;
 proxy_set_header X-Real-IP $remote_addr;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 }
}

X-Forwarded-For and X-Real-IP headers pass the original client IP to the upstream — without these the application sees only the proxy address.

SSL termination

NGINX handles TLS and speaks plain HTTP to backends. This centralises certificate management and offloads crypto from application processes:

server {
 listen 443 ssl;
 server_name example.com;

 ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
 ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
 ssl_protocols TLSv1.2 TLSv1.3;

 location / {
 proxy_pass http://127.0.0.1:8080;
 }
}

# Redirect HTTP → HTTPS
server {
 listen 80;
 server_name example.com;
 return 301 https://$host$request_uri;
}

Pair with Let’s Encrypt and Certbot for automated certificate issuance and renewal.

Load balancing

NGINX distributes traffic across multiple upstream instances using an upstream block:

upstream app {
 server 10.0.0.1:8080;
 server 10.0.0.2:8080;
 server 10.0.0.3:8080;
}

server {
 listen 80;
 location / {
 proxy_pass http://app;
 }
}

Default is round-robin. Other strategies: least_conn (fewest active connections), ip_hash (sticky sessions by client IP), hash (consistent hashing by arbitrary key).

Static files

NGINX serves static assets efficiently — far more so than most application frameworks. A common pattern: serve static files directly from NGINX, proxy only dynamic requests to the application.

location /static/ {
 alias /var/www/static/;
 expires 1y;
 add_header Cache-Control "public, immutable";
}

location / {
 proxy_pass http://app;
}

Useful patterns

Rate limiting — protect endpoints from abuse:

limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;

location /api/ {
 limit_req zone=api burst=20 nodelay;
 proxy_pass http://app;
}

Health check path — expose a simple status endpoint:

location /healthz {
 access_log off;
 return 200 "ok\n";
 add_header Content-Type text/plain;
}

Test config before reloading: nginx -t. Reload without dropping connections: nginx -s reload.

Resources

Reloader

Mon, 01 Jan 2024 00:00:00 +0000

Reloader is a Kubernetes controller from Stakater that watches ConfigMaps and Secrets and automatically triggers rolling restarts of Deployments, StatefulSets, and DaemonSets when the watched resources change. Kubernetes does not do this natively — updating a ConfigMap does not restart pods that consume it, so configuration changes don’t take effect until the next deploy.

Usage

Annotate a Deployment to watch a specific ConfigMap or Secret:

apiVersion: apps/v1
kind: Deployment
metadata:
 name: my-app
 annotations:
 reloader.stakater.com/auto: "true" # watch all referenced ConfigMaps/Secrets
 # OR be specific:
 configmap.reloader.stakater.com/reload: "my-config"
 secret.reloader.stakater.com/reload: "my-secret"

When the ConfigMap or Secret changes, Reloader detects it and triggers a rolling restart by updating a pod template annotation. The deployment rolls out new pods that pick up the updated configuration.

Installation

helm repo add stakater https://stakater.github.io/stakater-charts
helm install reloader stakater/reloader -n reloader --create-namespace

Why not use a hash annotation manually

The common alternative is to inject a hash of the ConfigMap into the pod template annotations via Helm or Kustomize — when the hash changes, Kubernetes rolls the deployment. This works but requires build-time tooling. Reloader handles it at runtime without any changes to the deployment pipeline.

Resources

Virtualization — KVM and KubeVirt

Mon, 01 Jan 2024 00:00:00 +0000

KVM is the Linux kernel’s native hypervisor. KubeVirt extends Kubernetes to run virtual machines using KVM under the hood. They are the same virtualization layer at different levels of abstraction — KVM on bare metal, KubeVirt in a Kubernetes cluster.

KVM

Kernel-based Virtual Machine. KVM turns the Linux kernel into a hypervisor using hardware virtualization extensions (Intel VT-x, AMD-V). Virtual machines run as regular Linux processes backed by QEMU for device emulation. Managed via libvirt and its CLI tools (virsh, virt-install) or the virt-manager GUI.

# Create a VM from an ISO
virt-install \
 --name ubuntu-vm \
 --ram 4096 \
 --vcpus 2 \
 --disk path=/var/lib/libvirt/images/ubuntu.qcow2,size=40 \
 --cdrom /tmp/ubuntu.iso \
 --os-variant ubuntu22.04

# List running VMs
virsh list

# Start/stop
virsh start ubuntu-vm
virsh shutdown ubuntu-vm

# Connect to console
virsh console ubuntu-vm

KVM gives near-native performance for CPU-bound workloads. Network and disk I/O use virtio drivers for efficient paravirtualised I/O. Live migration moves a running VM between hosts without downtime if shared storage is available.

KubeVirt

KubeVirt adds VirtualMachine and VirtualMachineInstance CRDs to Kubernetes. VMs are defined as Kubernetes resources, scheduled by the Kubernetes scheduler, and managed alongside containers. Under the hood, each VM runs as a pod containing a QEMU-KVM process.

apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
 name: ubuntu-vm
spec:
 running: true
 template:
 spec:
 domain:
 devices:
 disks:
 - name: rootdisk
 disk:
 bus: virtio
 resources:
 requests:
 memory: 4Gi
 cpu: "2"
 volumes:
 - name: rootdisk
 containerDisk:
 image: kubevirt/fedora-cloud-container-disk-demo

The virtctl CLI complements kubectl for VM-specific operations:

virtctl start ubuntu-vm
virtctl stop ubuntu-vm
virtctl console ubuntu-vm # serial console
virtctl ssh ubuntu-vm # SSH via the Kubernetes API
virtctl migrate ubuntu-vm # live migrate to another node

CDI — Containerized Data Importer

KubeVirt is typically paired with CDI, which imports VM disk images from URLs, container registries, or PVCs into DataVolume resources that VMs can boot from. CDI handles the data flow; the VM definition just references the DataVolume.

Why VMs in Kubernetes

Some workloads can’t be containerised — legacy applications expecting a full OS, Windows workloads, software with kernel module requirements. KubeVirt lets those workloads live in the same cluster as containers, managed with the same tooling, subject to the same scheduling and networking policies.

Frameworks & Tools on Backend Engineering Strategy Tools

Backstage

Core plugins

Software Catalog

Scaffolder (Software Templates)

TechDocs

Search

Entity model

Architecture

Getting started

Helm chart (production)

app-config.yaml

Plugin ecosystem

Adoption pattern

Resources

Blender Python — Procedural Mesh for 3D Printing

When to use this vs. alternatives

Core pattern

Running the script

Key API surface

Primitives

Transforms

bmesh (direct vertex / edge / face editing)

Boolean modifiers

Joining objects (single boolean cut for a grid of holes)

STL export (Blender 4.x / 5.x)

Collections (organising multi-part output)

Parametric families

Clearing the scene before a run

Viewport layout before export

Working with Claude

Limitations

Related

Code Quality & Architecture Analysis

SonarQube

Structure101

Resources

Docker & OCI

OCI images and containers

Dockerfile

Volumes and bind mounts

Networking

Podman

Buildah

Docker Compose

Skopeo

ORAS

Useful practices

Resources

Elasticsearch & Kibana

Elasticsearch

Kibana

ELK vs the Grafana stack

Resources

IntelliJ IDEA

Key capabilities

Plugins

Remote development

Resources

K9s & Lens

K9s

Navigation

Why TUI over GUI

Lens

kubectx / kubens

Resources

Nexus Repository

Why it exists

Repository types

Docker integration

Maven integration

Resources

NGINX

Server blocks

Reverse proxy

SSL termination

Load balancing

Static files

Useful patterns

Resources