<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:creativeCommons="http://backend.userland.com/creativeCommonsRssModule"><channel><title>Blog | 208.fi</title><link>https://208.fi/en/blog/</link><description>On the digital security in the full Internet stack</description><generator>Hugo</generator><language>en-GB</language><copyright>Project Organisation Helsinki</copyright><creativeCommons:license>https://creativecommons.org/licenses/by/4.0/</creativeCommons:license><lastBuildDate>Sat, 19 Sep 2026 18:30:00 +0300</lastBuildDate><atom:link href="https://208.fi/en/blog/index.xml" rel="self" type="application/rss+xml"/><item><title>High availability and distributed architecture</title><link>https://208.fi/en/blog/high-availability/</link><pubDate>Sat, 19 Sep 2026 18:30:00 +0300</pubDate><guid>https://208.fi/en/blog/high-availability/</guid><description>&lt;p&gt;A high availability service is available with a high probability.&#10;When a service is distributed to multiple independent servers, an&#10;individual server receives fewer requests. This improves not only the&#10;throughput or latency but also the fault tolerance. Should one of our&#10;&lt;a href="https://208.fi/en/term/dns/"&gt;name servers&lt;/a&gt; slow down or hang, others would guarantee&#10;continued service.&lt;/p&gt;&#10;&lt;p&gt;In theory, the source of a disruption does not actually matter. By&#10;far, the most probable &lt;q&gt;fault&lt;/q&gt; of our name servers ought to be&#10;the regular update of service containers and the content, which will&#10;disable one server at a time for a short duration. Because the&#10;function of the updated device will be checked before proceeding to&#10;the next one, the update can harm at most one device. If necessary, it&#10;can be rolled back to the pre-update state. During this time, other&#10;servers will keep the service available. In our case, all this happens&#10;automatically in &lt;a href="https://208.fi/en/blog/private-gitlab-erp/"&gt;our GitLab based ERP&#10;system&lt;/a&gt;.&lt;/p&gt;</description></item><item><title>Our sovereign GitLab ERP system deployment</title><link>https://208.fi/en/blog/private-gitlab-erp/</link><pubDate>Sat, 12 Sep 2026 12:45:00 +0300</pubDate><guid>https://208.fi/en/blog/private-gitlab-erp/</guid><description>&lt;p&gt;&lt;a href="https://projectorganisationhelsinki.fi/en/continuity/"&gt;Business continuity&#10;management&lt;/a&gt; is&#10;one of our lines of business. How do we practice it ourselves? The&#10;&lt;q&gt;brain&lt;/q&gt; of the company is an &lt;em&gt;enterprise resource planning&lt;/em&gt; (ERP)&#10;system that is in charge of all business related activity, such as the&#10;publication of this blog post.&lt;/p&gt;&#10;&lt;p&gt;Based on prior experience we chose GitLab. Not the service&#10;&lt;a href="https://gitlab.com"&gt;gitlab.com&lt;/a&gt; but an&#10;&lt;a href="https://docs.gitlab.com/install/"&gt;installation&lt;/a&gt; of the open source&#10;software in our private network.&lt;/p&gt;&#10;&lt;p&gt;To ensure data security, we run our own LDAP service and private key&#10;infrastructure (PKI). The containers of all services are built&#10;based on GitLab pipelines and schedules in closed &lt;code&gt;gitlab-runner&lt;/code&gt;&#10;containers running in an isolated environment. Situational awareness&#10;is provided by a centralised logging service. This is also how the&#10;&lt;a href="https://208.fi/en/products/gitlab/"&gt;GitLab service&lt;/a&gt; that we offer to our customers works.&lt;/p&gt;</description></item></channel></rss>