Freelance Java consultant with 20+ years of experience in cloud-native, microservices, and DevOps. https://remus-software.org/ Tom Seidel tom.seidel@remus-software.org 2026-04-04T00:00:00.000Z https://remus-software.org/articles/rest-explorer-1-0-released/ 2026-04-04T00:00:00.000Z 2026-04-04T00:00:00.000Z

Restic Explorer 1.0 is out — a lightweight, self-hosted web dashboard that monitors all restic backup repositories across S3, Azure, SFTP, REST, and Rclone from a single UI with automated scans, integrity checks, and retention policy tracking.

<p><strong>Backups are only as good as the confidence that they actually work.</strong> Restic Explorer 1.0 is now available — a focused, self-hosted web dashboard that provides exactly that confidence for all <a href="https://restic.net/">restic</a> repositories in one place.</p> <p><img src="https://raw.githubusercontent.com/tmseidel/restic-explorer/main/docs/screenshot_dashboard.png" alt="Restic Explorer Dashboard"></p> <h2 id="the-problem" tabindex="-1"><a class="header-anchor" href="#the-problem">The Problem</a></h2> <p>Restic is an outstanding backup tool. Fast, encrypted, deduplicated — it has become the go-to choice for backing up servers, NAS devices, and cloud workloads. But restic is a CLI tool by design. When running multiple repositories across different backends — S3 buckets, Azure Blob, SFTP servers — keeping track of <em>“is everything still running?”</em> becomes a chore. It often means writing shell scripts, parsing JSON output, wiring up cron jobs, and hoping someone notices when something breaks.</p> <p>Existing monitoring solutions are excellent pieces of software, but they tend to come with far more complexity than many use cases require: agent-based architectures, extensive plugin systems, or dashboards designed for hundreds of repositories across large teams. For operators who simply need a single pane of glass that answers <strong>are the backups running, are they healthy, and do they meet retention requirements?</strong> — a lighter approach is needed.</p> <h2 id="the-solution" tabindex="-1"><a class="header-anchor" href="#the-solution">The Solution</a></h2> <p>Restic Explorer is that single pane of glass. It connects directly to restic repositories — wherever they live — and provides:</p> <ul> <li><strong>Multi-Repository Dashboard</strong> — status of all repos at a glance with color-coded badges (green/red/amber)</li> <li><strong>Automated Scanning</strong> — scheduled <code>restic snapshots</code> calls cache metadata for fast browsing without CLI round-trips</li> <li><strong>Integrity Checks</strong> — scheduled <code>restic check --read-data</code> runs with configurable intervals per repository</li> <li><strong>Retention Policy Monitoring</strong> — daily/weekly/monthly/yearly rules with soft warnings when snapshots fall short</li> <li><strong>Health Endpoint</strong> — <code>/actuator/health</code> JSON endpoint reporting per-repo status, ready for Uptime Kuma, Prometheus, or any HTTP health checker</li> <li><strong>Snapshot Browser</strong> — paginated, sortable snapshot list with a dedicated detail page showing paths, tags, hostname, and size</li> <li><strong>Lock Detection</strong> — automatic stale lock detection with one-click unlock</li> <li><strong>Encrypted Credentials</strong> — AES-256-GCM encryption at rest for repository passwords and backend keys</li> </ul> <h3 id="five-backends%2C-one-ui" tabindex="-1"><a class="header-anchor" href="#five-backends%2C-one-ui">Five Backends, One UI</a></h3> <table> <thead> <tr> <th>Backend</th> <th>What it covers</th> </tr> </thead> <tbody> <tr> <td><strong>S3 / S3-Compatible</strong></td> <td>AWS S3, MinIO, Wasabi, Backblaze B2 (S3 API)</td> </tr> <tr> <td><strong>Azure Blob Storage</strong></td> <td>Native Azure integration</td> </tr> <tr> <td><strong>SFTP</strong></td> <td>Any SSH-accessible server, key-based auth</td> </tr> <tr> <td><strong>REST Server</strong></td> <td>Restic’s own REST backend with optional HTTP auth</td> </tr> <tr> <td><strong>Rclone</strong></td> <td>Google Drive, Dropbox, OneDrive, B2, and 40+ more via rclone</td> </tr> </tbody> </table> <h2 id="getting-started-in-60-seconds" tabindex="-1"><a class="header-anchor" href="#getting-started-in-60-seconds">Getting Started in 60 Seconds</a></h2> <p>The fastest way to get running is Docker Compose:</p> <pre><code class="language-yaml">services: app: image: tmseidel/restic-explorer:latest ports: - "8080:8080" environment: SPRING_PROFILES_ACTIVE: docker DB_HOST: db DB_PORT: 5432 DB_NAME: resticexplorer DB_USER: resticexplorer DB_PASSWORD: resticexplorer depends_on: db: condition: service_healthy restart: unless-stopped db: image: postgres:16-alpine environment: POSTGRES_DB: resticexplorer POSTGRES_USER: resticexplorer POSTGRES_PASSWORD: resticexplorer volumes: - db-data:/var/lib/postgresql/data healthcheck: test: ["CMD-SHELL", "pg_isready -U resticexplorer"] interval: 10s timeout: 5s retries: 5 restart: unless-stopped volumes: db-data: </code></pre> <pre><code class="language-bash">docker compose up -d </code></pre> <p>Open <code>http://localhost:8080</code>, create the admin account, and start adding repositories. That’s it.</p> <p>The image ships with restic, rclone, and openssh-client pre-installed — no additional setup required for any backend type.</p> <h2 id="why-restic-is-a-great-fit-for-cloud-%26-infrastructure-as-code" tabindex="-1"><a class="header-anchor" href="#why-restic-is-a-great-fit-for-cloud-%26-infrastructure-as-code">Why Restic is a Great Fit for Cloud & Infrastructure-as-Code</a></h2> <p>For teams managing cloud infrastructure through Terraform, Ansible, Pulumi, or similar tools, restic fits naturally into the workflow:</p> <h3 id="stateless-by-design" tabindex="-1"><a class="header-anchor" href="#stateless-by-design">Stateless by Design</a></h3> <p>Restic repositories are self-contained. There is no central server, no daemon, no database to maintain. A repository is just a structured set of encrypted blobs in any storage backend. This makes restic trivially reproducible — IaC can provision the storage bucket and the backup job in the same run.</p> <h3 id="backend-agnostic" tabindex="-1"><a class="header-anchor" href="#backend-agnostic">Backend Agnostic</a></h3> <p>Moving from AWS to Azure? Migrating from on-prem to cloud? Restic’s backend abstraction means the backup strategy isn’t tied to a vendor. A Terraform module provisions an S3 bucket today; tomorrow it provisions Azure Blob Storage. The restic commands stay the same.</p> <h3 id="encryption-without-infrastructure" tabindex="-1"><a class="header-anchor" href="#encryption-without-infrastructure">Encryption Without Infrastructure</a></h3> <p>Restic encrypts everything client-side. There is no need for a KMS, a Vault instance, or an HSM for backup encryption. One password, stored in the secrets manager of choice, and data is encrypted at rest regardless of the storage backend’s capabilities.</p> <h3 id="deduplication-saves-cloud-storage-costs" tabindex="-1"><a class="header-anchor" href="#deduplication-saves-cloud-storage-costs">Deduplication Saves Cloud Storage Costs</a></h3> <p>Restic’s content-defined chunking and deduplication means incremental backups are genuinely incremental — even across different source machines backing up to the same repository. In cloud environments where storage is metered, this translates directly to lower costs.</p> <h3 id="scriptable-and-composable" tabindex="-1"><a class="header-anchor" href="#scriptable-and-composable">Scriptable and Composable</a></h3> <p>Restic is a CLI tool that outputs JSON. It composes perfectly with cron, systemd timers, CI/CD pipelines, and container sidecars. No agents to install, no ports to open, no protocols to configure — just a binary and a repository URL.</p> <p>Restic Explorer adds the monitoring layer on top: existing restic workflows remain untouched, and Restic Explorer watches the repositories and surfaces issues when they need attention.</p> <h2 id="what%E2%80%99s-in-1.0" tabindex="-1"><a class="header-anchor" href="#what%E2%80%99s-in-1.0">What’s in 1.0</a></h2> <p>This release marks the point where the feature set is stable, tested, and production-ready:</p> <ul> <li><strong>Five backend types</strong> — S3, Azure, SFTP, REST, Rclone</li> <li><strong>Repository groups</strong> — organize repos by team, environment, or purpose</li> <li><strong>Configurable scan and check intervals</strong> per repository</li> <li><strong>Retention policy monitoring</strong> with violation warnings</li> <li><strong>Error log</strong> with date filtering and auto-cleanup</li> <li><strong>Dark mode</strong> with automatic theme detection</li> <li><strong>Health & info endpoints</strong> for external monitoring integration</li> <li><strong>Admin-only download</strong> of snapshots as <code>.tar</code> archives</li> <li><strong>Encrypted credential storage</strong> (AES-256-GCM)</li> <li><strong>Docker image</strong> running as non-root user with built-in healthcheck</li> </ul> <table> <thead> <tr> <th>Snapshots</th> <th>Snapshot Detail</th> </tr> </thead> <tbody> <tr> <td><img src="https://raw.githubusercontent.com/tmseidel/restic-explorer/main/docs/screenshot_snapshots.png" alt="Snapshots"></td> <td><img src="https://raw.githubusercontent.com/tmseidel/restic-explorer/main/docs/screenshot_snapshot.png" alt="Detail"></td> </tr> </tbody> </table> <h2 id="get-it" tabindex="-1"><a class="header-anchor" href="#get-it">Get It</a></h2> <ul> <li><strong>Docker Hub</strong>: <a href="https://hub.docker.com/r/tmseidel/restic-explorer"><code>tmseidel/restic-explorer:latest</code></a></li> <li><strong>GitHub</strong>: <a href="https://github.com/tmseidel/restic-explorer">tmseidel/restic-explorer</a></li> <li><strong>Documentation</strong>: <a href="https://github.com/tmseidel/restic-explorer/blob/main/docs/USER_GUIDE.md">User Guide</a> · <a href="https://github.com/tmseidel/restic-explorer/blob/main/docs/CONFIGURATION.md">Configuration</a> · <a href="https://github.com/tmseidel/restic-explorer/blob/main/docs/ARCHITECTURE.md">Architecture</a></li> </ul> <p>Licensed under MIT. Contributions, issues, and feedback welcome.</p> <hr> <p><em>Restic Explorer is built with Spring Boot 4, Thymeleaf, and Bootstrap 5. It runs as a single container alongside PostgreSQL and requires no additional infrastructure beyond what is already in place.</em></p> Tom Seidel https://remus-software.org/articles/replacing-veeam-with-restic/ 2026-03-29T00:00:00.000Z 2026-03-29T00:00:00.000Z

How we replaced a costly, complex backup system with a simple shell script and S3 storage — and the key questions to ask before you do the same.

<h1 id="" tabindex="-1"><a class="header-anchor" href="#"></a></h1> <p><strong>We ditched our expensive, bloated backup platform for a shell script and S3. Here’s how — and what to think about before you do the same.</strong></p> <hr> <h2 id="the-problem-nobody-wants-to-touch" tabindex="-1"><a class="header-anchor" href="#the-problem-nobody-wants-to-touch">The Problem Nobody Wants to Touch</a></h2> <p>Let’s be honest: most backup systems are set up once and then nobody looks at them again. They just… run. Hopefully.</p> <p>We were in that exact spot. A centralized commercial backup server on Windows, proprietary agents on every machine, enterprise licenses, the whole deal. It worked — until it didn’t:</p> <ul> <li><strong>The config kept breaking.</strong> More than once, the backup server’s internal state got corrupted. Trying to add a new backup job? Error dialog. Can’t configure anything until someone fixes it manually.</li> <li><strong>Way too much overhead.</strong> Each server needed a proprietary agent, a service user, SSH access, firewall rules — all for what’s basically “copy some files somewhere safe.”</li> <li><strong>We used 5% of the features.</strong> Bare-metal recovery? Granular restore? Application-aware snapshots? We never used any of that. Our servers are provisioned with automation — we can rebuild them from scratch. We just needed the <em>data</em>.</li> <li><strong>It cost real money.</strong> A Windows Server with commercial licenses, just to store backups. For a team that runs Linux everywhere else, that’s an expensive oddball.</li> </ul> <hr> <h2 id="before-you-migrate%3A-ask-yourself-these-questions" tabindex="-1"><a class="header-anchor" href="#before-you-migrate%3A-ask-yourself-these-questions">Before You Migrate: Ask Yourself These Questions</a></h2> <p>Don’t jump to a new tool just because the old one annoys you. Think it through first:</p> <ul> <li><strong>What are you actually backing up?</strong> If your servers can be rebuilt from code, you probably just need data-level backups (database dumps, config files), not full disk images.</li> <li><strong>Have you ever restored from backup?</strong> If the answer is “uh, I think so?” — that’s your real problem, regardless of the tool.</li> <li><strong>What’s the total cost?</strong> Licenses + the server it runs on + agent maintenance + engineer time spent debugging weird issues.</li> <li><strong>Do you get alerts when a backup fails?</strong> A backup that silently breaks is worse than no backup at all.</li> <li><strong>Is backup part of your provisioning?</strong> If setting up backup for a new server is a separate manual process, it <em>will</em> get skipped eventually.</li> </ul> <hr> <h2 id="what-we-switched-to" tabindex="-1"><a class="header-anchor" href="#what-we-switched-to">What We Switched To</a></h2> <p>We landed on <a href="https://restic.net/">Restic</a> — open-source, encrypts everything, deduplicates, compresses, and stores to any S3-compatible backend. It’s in the default Debian repos. Install is literally <code>apt install restic</code>.</p> <table> <thead> <tr> <th></th> <th>Old System</th> <th>Restic</th> </tr> </thead> <tbody> <tr> <td><strong>Install</strong></td> <td>Proprietary repo + agent + service user + firewall rules</td> <td><code>apt install restic</code></td> </tr> <tr> <td><strong>Storage</strong></td> <td>Dedicated Windows backup server</td> <td>Any S3-compatible object storage</td> </tr> <tr> <td><strong>Config</strong></td> <td>GUI on backup server</td> <td>Environment variables + shell script</td> </tr> <tr> <td><strong>Licensing</strong></td> <td>Per-server commercial license</td> <td>Free</td> </tr> <tr> <td><strong>Restore</strong></td> <td>Through backup server UI</td> <td><code>restic restore</code> from anywhere</td> </tr> </tbody> </table> <p>When picking any replacement tool, look for: simple deployment, storage flexibility (don’t get locked in), full CLI scriptability, client-side encryption, active community, and built-in retention management.</p> <hr> <h2 id="the-architecture" tabindex="-1"><a class="header-anchor" href="#the-architecture">The Architecture</a></h2> <p>Here’s what we ended up with — three layers:</p> <div class="mermaid">graph TB subgraph servers["Servers"] native["<b>Native App</b><br/>pg_dumpall → gzip<br/>→ restic backup"] docker["<b>Docker App</b><br/>docker exec → pg_dump<br/>→ gzip → restic backup"] legacy["<b>Legacy App</b><br/>mysqldump<br/>→ legacy agent"] end subgraph storage["Storage Layer"] s3["<b>S3-Compatible Object Store</b><br/>One bucket per project"] legacysrv["<b>Legacy Backup Server</b>"] end subgraph monitoring["Monitoring Layer"] explorer["<b>Backup Explorer</b><br/>Browse repos,<br/>check health"] heartbeat["<b>Heartbeat Monitor</b><br/>Push-based alerts on<br/>success / failure"] end native -- "Restic + S3" --> s3 docker -- "Restic + S3" --> s3 legacy -- "Legacy Agent" --> legacysrv s3 --> explorer s3 --> heartbeat </div><p>A few rules we learned the hard way:</p> <ul> <li><strong>One bucket per project.</strong> Never mix backups from different apps in the same bucket. Isolation, access control, cost tracking — all easier this way.</li> <li><strong>Every backup is individual.</strong> A Postgres DB needs <code>pg_dumpall</code>. A Docker service needs <code>docker compose exec</code>. A VPN server needs its config files. There’s no universal “back up everything” script. Write one per app.</li> <li><strong>Credentials go in a team vault.</strong> If the person who set up the backup leaves, you don’t want the passwords leaving with them.</li> </ul> <hr> <h2 id="the-script-pattern" tabindex="-1"><a class="header-anchor" href="#the-script-pattern">The Script Pattern</a></h2> <p>After iterating across a bunch of projects, we settled on a template every backup job follows:</p> <pre><code class="language-bash">#!/usr/bin/env bash set -euo pipefail source /opt/app/.restic-env # Error trap — always notify on failure trap 'notify_monitor "down" "Backup failed"; rm -f "${DUMP_FILE}"; exit 1' ERR # Init repo if first run restic snapshots > /dev/null 2>&1 || restic init # Create the dump (customize this per app) pg_dumpall | gzip > "${DUMP_FILE}" # Don't upload empty dumps [[ -s "${DUMP_FILE}" ]] || { notify_monitor "down" "Empty dump"; exit 1; } # Upload, clean up, prune old snapshots restic backup "${DUMP_FILE}" --tag app-name rm -f "${DUMP_FILE}" restic forget --keep-daily 30 --keep-weekly 8 --keep-monthly 12 --prune # All good notify_monitor "up" "OK" </code></pre> <p>The important bits: the <strong>error trap</strong> makes sure you hear about failures. The <strong>empty-dump check</strong> catches silent breakage (like a database dump that exits 0 but produces nothing). <strong>Retention runs on every backup</strong>, not as a separate task. And <strong>tags</strong> let you filter snapshots later.</p> <p>With default retention (30 daily, 8 weekly, 12 monthly) you end up with about 44 snapshots at any given time — good granularity without blowing up storage.</p> <hr> <h2 id="monitoring%3A-don%E2%80%99t-skip-this" tabindex="-1"><a class="header-anchor" href="#monitoring%3A-don%E2%80%99t-skip-this">Monitoring: Don’t Skip This</a></h2> <p>Two layers — you need both:</p> <p><strong>Heartbeat monitoring:</strong> Every backup script pings a monitor on success or failure (we use <a href="https://github.com/louislam/uptime-kuma">Uptime Kuma</a>, but anything push-based works). If no ping arrives within 26 hours → alert. This catches script failures, cron being broken, and servers being down.</p> <pre><code class="language-bash">curl -sf "${MONITOR_URL}?status=up&msg=OK" # on success curl -sf "${MONITOR_URL}?status=down&msg=Failed" # in error trap </code></pre> <p><strong>Repository browser:</strong> A heartbeat tells you <em>if</em> the backup ran. A browser tells you <em>what’s in it</em> — snapshot counts, sizes, retention compliance, integrity checks. This catches things like backups that “succeed” but are suspiciously small.</p> <hr> <h2 id="how-to-actually-migrate" tabindex="-1"><a class="header-anchor" href="#how-to-actually-migrate">How to Actually Migrate</a></h2> <p>Don’t flip the switch overnight. We did it in phases:</p> <ol> <li><strong>New servers get the new tool from day one.</strong> Zero risk, no migration needed.</li> <li><strong>Old servers run both systems in parallel.</strong> Set up the new backup alongside the legacy one.</li> <li><strong>Test restores from the new backup.</strong> Actually restore on a test environment. Verify the data.</li> <li><strong>Remove the legacy agent per server</strong> after the new backup has been solid for a couple of months.</li> <li><strong>Kill the legacy server last</strong> — only after every server is migrated and validated.</li> </ol> <p>Don’t rush step 4. Storage is cheap. Lost data is not.</p> <hr> <h2 id="tl%3Bdr" tabindex="-1"><a class="header-anchor" href="#tl%3Bdr">TL;DR</a></h2> <ul> <li>If your servers are provisioned from code, you don’t need image-level backups. Just back up the data.</li> <li>Write a backup script per application — there is no one-size-fits-all.</li> <li>Monitor everything. Heartbeats for “did it run?”, a browser for “what’s in it?”</li> <li>Bake backup into your provisioning. If it’s manual, it’ll get skipped.</li> <li>Test your restores. A backup you’ve never restored from is a hope, not a strategy.</li> <li>Migrate gradually. Parallel-run, validate, then decommission.</li> </ul> <p>A shell script, a cron job, encrypted uploads to S3, and a heartbeat ping. That’s the whole system. No servers, no GUI, no licenses.</p> <hr> <p><em>The best backup system is the one your team actually understands, maintains, and tests.</em></p> Tom Seidel https://remus-software.org/articles/self-hosted-ai-translation-service/ 2026-02-02T00:00:00.000Z 2026-02-02T00:00:00.000Z

A practical evaluation of replacing DeepL with a self-hosted translation service using open-source LLMs — comparing quality, performance, and cost.

<p>With freely available large language models now widely accessible, it has become straightforward to self-host software that was previously only available through commercial providers. The key question always comes down to the resulting costs and the effort involved.</p> <p>In this case study, I examined whether the translation service DeepL can be replaced by a self-hosted solution. The goal was to provide a DeepL-compatible REST API that:</p> <ul> <li>achieves comparable translation quality,</li> <li>offers similar performance, and</li> <li>implements the same REST API specification<sup class="footnote-ref"><a href="#fn1" id="fnref1">[1]</a></sup>,</li> </ul> <p>in order to then compare the one-time and ongoing costs. Using the DeepL API requires a paid subscription; while the pay-as-you-go model is transparent, it can become very expensive with heavy usage. Additionally, data leaves the corporate network, and the API’s behaviour under heavy load is not fully transparent.</p> <h2 id="choosing-a-suitable-local-model" tabindex="-1"><a class="header-anchor" href="#choosing-a-suitable-local-model">Choosing a Suitable Local Model</a></h2> <p>The first question is which freely available models are suitable for translation tasks. Hugging Face offers a large selection of models that can be easily integrated into custom software<sup class="footnote-ref"><a href="#fn2" id="fnref2">[2]</a></sup>. For this evaluation, Meta’s <strong>nllb-200-distilled</strong> model was chosen, as it is widely used, easy to deploy, and available in three sizes (600M, 1.3B, and 3.3B parameters).</p> <h2 id="implementing-the-deepl-compatible-rest-api" tabindex="-1"><a class="header-anchor" href="#implementing-the-deepl-compatible-rest-api">Implementing the DeepL-Compatible REST API</a></h2> <p>A pragmatic approach was taken for the implementation: a Spring Boot application serves as the API frontend and delegates the actual translation request to a Python Flask component that controls the LLM.</p> <p>For easy deployment, the system can be run either:</p> <ul> <li>in Docker containers, or</li> <li>natively on a Debian/Ubuntu server.</li> </ul> <p>The goal was a straightforward deployment on various cloud hardware platforms to test quality and performance there. The complete implementation is available on GitHub<sup class="footnote-ref"><a href="#fn3" id="fnref3">[3]</a></sup>. Ansible was used for automated native deployment.</p> <h2 id="test-%E2%80%94-translation-quality" tabindex="-1"><a class="header-anchor" href="#test-%E2%80%94-translation-quality">Test — Translation Quality</a></h2> <p>The following German reference sentence was used to evaluate translation quality:</p> <blockquote> <p><em>“Sobald der Glasfaser-Ausbau abgeschlossen ist, erhalten Sie eine Mitteilung zum Schaltungstermin und eine Schnell-Start-Anleitung für die Einrichtung des Glasfaser-Anschlusses.”</em></p> </blockquote> <p>DeepL produces the following translation:</p> <blockquote> <p>“Once the fiber optic expansion is complete, you will receive a notification of the activation date and a quick start guide for setting up your fiber optic connection.”</p> </blockquote> <p>This translation serves as the reference.</p> <h3 id="test-with-nllb-200-distilled-600m" tabindex="-1"><a class="header-anchor" href="#test-with-nllb-200-distilled-600m">Test with nllb-200-distilled-600M</a></h3> <p>The smallest model was first run on a development machine via Docker. Performance was not a concern at this stage. The generated translation was:</p> <blockquote> <p>“Once the glass-faser-Ausbau is closed, you receive a Mitteilung zum Schaltungstermin und eine Schnell-Start-Anleitung für die Einrichtung der Glasfaser-Anschlusses.”</p> </blockquote> <p><img src="nllb-200-distilled-600M.png" alt="Response of the small model"></p> <h3 id="test-with-nllb-200-distilled-1.3b" tabindex="-1"><a class="header-anchor" href="#test-with-nllb-200-distilled-1.3b">Test with nllb-200-distilled-1.3B</a></h3> <p>The medium model produced the following output:</p> <blockquote> <p>“The Commission shall inform the Member States of the date of the entry into force of this Regulation.”</p> </blockquote> <h3 id="test-with-nllb-200-distilled-3.3b" tabindex="-1"><a class="header-anchor" href="#test-with-nllb-200-distilled-3.3b">Test with nllb-200-distilled-3.3B</a></h3> <p>The largest model generated the following translation:</p> <blockquote> <p>“Once the glass fibre installation is completed, you will receive a notice on the date of installation and a quick start guide for the installation of the glass fibre connections.”</p> </blockquote> <p><img src="nllb-200-distilled-3.3B.png" alt="Response of the large model"></p> <h3 id="translation-quality-conclusion" tabindex="-1"><a class="header-anchor" href="#translation-quality-conclusion">Translation Quality Conclusion</a></h3> <p>A comprehensive assessment is difficult after just a few tests. Nevertheless, it became clear that only the largest model is viable for production use. It was also notable that the models performed significantly more reliably when the source language was English. If translation is exclusively from English, the medium model might therefore be sufficient.</p> <h2 id="test-%E2%80%94-performance" tabindex="-1"><a class="header-anchor" href="#test-%E2%80%94-performance">Test — Performance</a></h2> <p>Once the suitable model was identified, the next step was to determine under which hardware conditions productive operation is feasible. As a benchmark, it was assumed that translating the reference sentence should take no longer than two seconds. Additionally, the difference between a traditional CPU-based server and a GPU-based system was to be determined.</p> <h3 id="test%3A-traditional-server" tabindex="-1"><a class="header-anchor" href="#test%3A-traditional-server">Test: Traditional Server</a></h3> <p>A Hetzner CX53 with 16 vCPUs and 32 GB RAM was used as the CPU server (cost: €17 per month).</p> <p><strong>Response time: 12.93 seconds</strong></p> <h3 id="test%3A-gpu-server" tabindex="-1"><a class="header-anchor" href="#test%3A-gpu-server">Test: GPU Server</a></h3> <p>An Amazon g4dn.large with 16 GB GPU RAM (Nvidia) was used as the GPU server. The cost is €0.67 per hour, roughly €500 per month.</p> <p><strong>Response time: 1.31 seconds</strong> — GPU memory usage: approx. 13 GB</p> <h3 id="performance-conclusion" tabindex="-1"><a class="header-anchor" href="#performance-conclusion">Performance Conclusion</a></h3> <p>The difference between the two systems was significantly larger than expected. Even without deep knowledge of the internal workings of LLMs, it is clear that productive operation is practically only feasible with GPU-based hardware. Costs on AWS are currently high, but cheaper alternatives exist — for example at Hetzner<sup class="footnote-ref"><a href="#fn4" id="fnref4">[4]</a></sup>. The achieved response time is fundamentally suitable for production use. Parallel requests had no significant impact on latency in the tests.</p> <p><img src="nvidia-smi.png" alt="nvidia-smi output showing GPU memory usage"></p> <h2 id="overall-conclusion" tabindex="-1"><a class="header-anchor" href="#overall-conclusion">Overall Conclusion</a></h2> <p>This evaluation clearly demonstrates that it is possible to self-host AI-based services like machine translation using freely available models and modern hardware — with reasonable effort and competitive quality. While the ongoing costs for GPU-based systems are still relatively high, falling prices and increasing efficiency can be expected as adoption grows and technology advances. Moreover, more affordable hosting alternatives beyond the major cloud providers already exist today.</p> <p>Especially in heavily regulated industries — such as finance, healthcare, or the public sector — a self-hosted AI service can offer significant advantages:</p> <ul> <li><strong>Data sovereignty</strong> is fully preserved, as no sensitive information leaves external systems.</li> <li><strong>Compliance requirements</strong> are easier to meet, since infrastructure and data flows are fully controllable.</li> <li><strong>Performance and scalability</strong> can be precisely tailored to your own needs.</li> <li><strong>Competitive advantages</strong> emerge when you can offer services that are not only cheaper but also more secure and flexible than commercial alternatives.</li> </ul> <h2 id="references" tabindex="-1"><a class="header-anchor" href="#references">References</a></h2> <hr class="footnotes-sep"> <section class="footnotes"> <ol class="footnotes-list"> <li id="fn1" class="footnote-item"><p><a href="https://developers.deepl.com/docs/getting-started/intro">DeepL API Documentation</a> <a href="#fnref1" class="footnote-backref">↩︎</a></p> </li> <li id="fn2" class="footnote-item"><p><a href="https://huggingface.co/models?pipeline_tag=translation">Hugging Face Translation Models</a> <a href="#fnref2" class="footnote-backref">↩︎</a></p> </li> <li id="fn3" class="footnote-item"><p><a href="https://github.com/tmseidel/simple_ai_translation_service">simple_ai_translation_service on GitHub</a> <a href="#fnref3" class="footnote-backref">↩︎</a></p> </li> <li id="fn4" class="footnote-item"><p><a href="https://www.hetzner.com/dedicated-rootserver/matrix-gpu/">Hetzner GPU Dedicated Servers</a> <a href="#fnref4" class="footnote-backref">↩︎</a></p> </li> </ol> </section> Tom Seidel https://remus-software.org/articles/monolith-to-microservices/ 2024-03-15T00:00:00.000Z 2024-03-15T00:00:00.000Z

A hands-on walkthrough of the architectural decisions and patterns I use when migrating Java monoliths to cloud-native microservices.

<p>Migrating a monolithic Java application to microservices is one of the most impactful — and challenging — transformations you can undertake. This article shares the practical approach I’ve refined over multiple engagements.</p> <h2 id="why-migrate%3F" tabindex="-1"><a class="header-anchor" href="#why-migrate%3F">Why Migrate?</a></h2> <p>Before touching a single line of code, ask: <em>why are we doing this?</em> The most common drivers I encounter are:</p> <ul> <li><strong>Deployment bottlenecks</strong>: A single deployable artifact blocks independent team delivery.</li> <li><strong>Scalability constraints</strong>: You need to scale a specific module, not the entire application.</li> <li><strong>Technology modernisation</strong>: Teams want to adopt newer frameworks or languages for specific domains.</li> <li><strong>Organisational growth</strong>: Conway’s Law — architecture tends to mirror team structure.</li> </ul> <blockquote> <p>“Never migrate for migration’s sake. Identify the concrete pain point and validate that microservices solve it.”</p> </blockquote> <h2 id="the-strangler-fig-pattern" tabindex="-1"><a class="header-anchor" href="#the-strangler-fig-pattern">The Strangler Fig Pattern</a></h2> <p>My go-to approach is the <strong>Strangler Fig Pattern</strong>: incrementally replace monolith functionality behind a facade, leaving the monolith running until it’s fully strangled.</p> <div class="mermaid">graph LR Client -->|All traffic| Facade[API Gateway / Facade] Facade -->|Legacy routes| Monolith[(Monolith)] Facade -->|New routes| SvcA[User Service] Facade -->|New routes| SvcB[Order Service] Monolith -.->|Shared DB - phase 1| DB[(Database)] SvcA -->|Own DB - phase 2| DBA[(Users DB)] SvcB -->|Own DB - phase 2| DBB[(Orders DB)] </div><p>This lets you:</p> <ol> <li>Ship value incrementally</li> <li>Reduce risk by keeping the fallback running</li> <li>Validate each new service before extracting the next</li> </ol> <h2 id="identifying-service-boundaries" tabindex="-1"><a class="header-anchor" href="#identifying-service-boundaries">Identifying Service Boundaries</a></h2> <p>Domain-Driven Design (DDD) gives us the best tools for finding service boundaries. I use <strong>Event Storming</strong> workshops to:</p> <ol> <li>Map all domain events with the business team</li> <li>Identify <strong>bounded contexts</strong> — areas with consistent language and ownership</li> <li>Use bounded contexts as candidate service boundaries</li> </ol> <div class="mermaid">graph TD subgraph "Order Context" OE1[OrderPlaced] OE2[OrderConfirmed] OE3[OrderShipped] end subgraph "Inventory Context" IE1[StockReserved] IE2[StockReleased] end subgraph "Notification Context" NE1[EmailSent] NE2[SMSSent] end OE2 --> IE1 OE3 --> NE1 IE2 --> NE2 </div><h2 id="practical-steps" tabindex="-1"><a class="header-anchor" href="#practical-steps">Practical Steps</a></h2> <h3 id="1.-start-with-the-api-layer" tabindex="-1"><a class="header-anchor" href="#1.-start-with-the-api-layer">1. Start with the API Layer</a></h3> <p>Deploy an <strong>API Gateway</strong> (AWS API Gateway, Kong, or a simple Spring Cloud Gateway) in front of the monolith. This gives you:</p> <ul> <li>A single entry point for traffic</li> <li>The ability to route selectively to new services</li> <li>A foundation for cross-cutting concerns (auth, rate limiting, logging)</li> </ul> <h3 id="2.-extract-stateless-services-first" tabindex="-1"><a class="header-anchor" href="#2.-extract-stateless-services-first">2. Extract Stateless Services First</a></h3> <p>Pick a bounded context that:</p> <ul> <li>Has clear, stable APIs</li> <li>Is relatively self-contained</li> <li>Has low coupling to the rest of the monolith</li> </ul> <p>Notification services, reporting modules, and authentication are often good first targets.</p> <h3 id="3.-database-decomposition" tabindex="-1"><a class="header-anchor" href="#3.-database-decomposition">3. Database Decomposition</a></h3> <p>The hardest part. Never share a database between the monolith and a new service in the long run. The interim approach:</p> <div class="mermaid">sequenceDiagram participant New Service participant Monolith participant Shared DB participant New DB Note over New Service, Shared DB: Phase 1 – Dual Write New Service->>Shared DB: Write (compatibility) New Service->>New DB: Write (new schema) Monolith->>Shared DB: Read/Write Note over New Service, New DB: Phase 2 – Cutover New Service->>New DB: Write only Monolith->>Shared DB: Read/Write (deprecated path) </div><h3 id="4.-embrace-eventual-consistency" tabindex="-1"><a class="header-anchor" href="#4.-embrace-eventual-consistency">4. Embrace Eventual Consistency</a></h3> <p>With separate services comes eventual consistency. Use <strong>domain events</strong> over synchronous REST calls wherever possible:</p> <ul> <li>Publish events to a message broker (Kafka, RabbitMQ)</li> <li>Services subscribe to relevant events</li> <li>Saga pattern for distributed transactions</li> </ul> <h2 id="key-takeaways" tabindex="-1"><a class="header-anchor" href="#key-takeaways">Key Takeaways</a></h2> <ul> <li><strong>Migrate iteratively</strong> — the Strangler Fig pattern is your friend.</li> <li><strong>Define clear boundaries</strong> using DDD bounded contexts.</li> <li><strong>Decouple the database</strong> as a separate, explicit step.</li> <li><strong>Invest in observability</strong> early — distributed tracing (Jaeger, Zipkin) and centralised logging (ELK stack) become essential.</li> <li><strong>Automate everything</strong> — CI/CD per service, infrastructure as code, automated testing.</li> </ul> <p>The migration journey is long, but each extracted service pays dividends in team autonomy and deployment velocity. Start small, validate, and build momentum.</p> Tom Seidel