language in article byline

Author: andnorda

src/routes/(pages)/blog/+page.server.ts

@@ -7,6 +7,7 @@ export async function load() {
 			author: string;
 			description: string;
 			draft?: boolean;
+			language?: string;
 		};
 	}>("./posts/*/+page.md", { eager: true });
 

src/routes/(pages)/blog/+page.svelte

@@ -1,6 +1,7 @@
 <script lang="ts">
 	import { format } from "date-fns";
 	import type { PageData } from "./$types";
+	import { nb } from "date-fns/locale";
 
 	let { data }: { data: PageData } = $props();
 </script>
@@ -14,7 +15,9 @@
 				</a>
 			</h2>
 			<div class="byline">
-				{format(post.metadata.date, "MMMM d, yyyy")} by {post.metadata.author}
+				{post.metadata.language === "en"
+					? `${format(post.metadata.date, "MMMM d, yyyy")} by ${post.metadata.author}`
+					: `${format(post.metadata.date, "d. MMMM yyyy", { locale: nb })} av ${post.metadata.author}`}
 			</div>
 			<div class="description">{post.metadata.description}</div>
 		</li>

src/routes/(pages)/blog/posts/adventskalender-2024/+page.md

@@ -5,6 +5,7 @@ date: 2024-12-01T22:10:00+02:00
 author: Naissen
 tags: []
 theme: advent
+language: nb
 ---
 
 La oss gjøre adventstiden mer nais med en Nais adventskalender! Her vil vi hver arbeidsdag legge ut et tips til hvordan du kan bruke Nais-plattformen.

src/routes/(pages)/blog/posts/changing-service-mesh/+page.md

@@ -5,9 +5,11 @@ date: 2021-05-04T20:37:13+02:00
 draft: false
 author: Frode Sundby
 tags: [istio, linkerd, LoadBalancing]
+language: en
 ---
 
 ## Why change?
+
 With an ambition of making our environments as secure as possible, we jumped on the service-mesh bandwagon in 2018 with Istio 0.7 and have stuck with it since.
 
 Istio is a large and feature rich system that brings capabilities aplenty.
@@ -27,7 +29,9 @@ Rarely has a meme depicted a feeling more strongly
 Even though we'd invested a lot of time and built in quite a bit of Istio into our platform, we knew we had to make the change.
 
 ## How did we do it?
-### Original architecture: 
+
+### Original architecture:
+
 Let's first have a quick look at what we were dealing with:
 
 The first thing an end user encountered was our Google LoadBalancer configured by an IstioOperator.
@@ -38,20 +42,22 @@ We used an [operator](https://github.com/nais/naiserator) to configure these pol
 ![changing-service-mesh-1](./images/changing-service-mesh-1.png)
 
 ### New LoadBalancers and ingress controllers
+
 Since our LoadBalancers were configured by (and sent traffic to) Istio, we had to change the way we configured them.
 Separating LoadBalancing from mesh is a healthy separation of concern that will give us greater flexibility in the future as well.
 We also had to swap out Istio Ingressgateway with an Ingress Controller - we opted for NGINX.
 
 We started by creating IP-addresses and Cloud Armor security policies for our new LoadBalancers with [Terraform](https://www.terraform.io/).
 
 The loadbalancers themselves were created by an Ingress object:
+
 ```yaml
 apiVersion: networking.k8s.io/v1beta1
 kind: Ingress
 metadata:
   annotations:
     networking.gke.io/v1beta1.FrontendConfig: <tls-config>
-    kubernetes.io/ingress.global-static-ip-name: <global-ip-name> 
+    kubernetes.io/ingress.global-static-ip-name: <global-ip-name>
     kubernetes.io/ingress.allow-http: "false"
   name: <loadbalancer-name>
   namespace: <ingress-controller-namespace>
@@ -64,6 +70,7 @@ spec:
 ```
 
 We tied the Cloud Armor security policy to the Loadbalancer with a `BackendConfig` on the Ingress Controller's service:
+
 ```yaml
 apiVersion: v1
 kind: Service
@@ -89,6 +96,7 @@ Alrighty. We'd now gotten ourselves a brand new set of independantly configured
 
 However - if we'd started shipping traffic to the new components at this stage, things would start breaking as there were no ingresses in the cluster - only VirtualServices.
 To avoid downtime, we created an interim ingress that forwarded all traffic to the Istio IngressGateway:
+
 ```yaml
 apiVersion: networking.k8s.io/v1beta1
 kind: Ingress
@@ -103,15 +111,18 @@ spec:
         path: /
   ...
 ```
+
 ![changing-service-mesh-3](./images/changing-service-mesh-3.png)
 With this ingress in place, we could reach all the existing VirtualServices exposed by the Istio Ingressgateway via the new Loadbalancers and Nginx.
 And we could point our DNS records to the new rig without anyone noticing a thing.
 
 ### Migrating workloads from Istio to Linkerd
-Once LoadBalancing  and ingress traffic were closed chapters, we changed our attention to migrating workloads from Istio to Linkerd.
+
+Once LoadBalancing and ingress traffic were closed chapters, we changed our attention to migrating workloads from Istio to Linkerd.
 When moving a workload to a new service-mesh, there's a bit more to it than swapping out the sidecar with a new namespace annotation.
 Our primary concerns were:
-- The new sidecar would require NetworkPolicies to allow traffic to and from linkerd. 
+
+- The new sidecar would require NetworkPolicies to allow traffic to and from linkerd.
 - The application's VirtualService would have to be transformed into an Ingress.
 - Applications that used [scuttle](https://github.com/redboxllc/scuttle) to wait for the Istio sidecar to be ready had to be disabled.
 - We couldn't possibly migrate all workloads simultaneously due to scale.
@@ -122,7 +133,7 @@ Using the NetworkPolicies to map out who were communicating with whom, we found
 
 We then gave this list to our [operator](https://github.com/nais/naiserator), who in turn removed Istio resources, updated NetworkPolicies, created Ingresses and restarted workloads.
 Slowly but surely our linkerd dashboard was starting to populate, and the only downtime was during the seconds it took for the first Linkerd pod to be ready.
-One thing we didn't take into concideration (but should have), was that some applications shared a hostname. 
+One thing we didn't take into concideration (but should have), was that some applications shared a hostname.
 When an ingress was created for a shared hostname, Nginx would stop forwarding requests for these hosts to Istio Ingressgateway, resulting in non-migrated applications not getting any traffic.
 Realizing this, we started migrating applications on the same hostname simultaneously too.
 
@@ -133,8 +144,8 @@ And then they all lived happily ever after...
 Except that we had to clean up Istio's mess.
 
 ### Cleaning up
-What was left after the party was a fully operational Istio control plane, a whole bunch of Istio CRD's and a completely unused set of LoadBalancers. In addition we had to clean up everything related to Istio in a whole lot of pipelines and components
 
+What was left after the party was a fully operational Istio control plane, a whole bunch of Istio CRD's and a completely unused set of LoadBalancers. In addition we had to clean up everything related to Istio in a whole lot of pipelines and components
 
 ![changing-service-mesh-5](./images/changing-service-mesh-5.png)
 ![changing-service-mesh-6](./images/changing-service-mesh-6.png)

src/routes/(pages)/blog/posts/data_mesh_governance/+page.md

@@ -5,7 +5,9 @@ date: 2022-05-11T09:27:57+02:00
 draft: false
 author: Louis Dieffenthaler
 tags: []
+language: en
 ---
+
 Using data to develop the world`s best welfare system is a bold mission we at the Norwegian Welfare and Labour Administration (NAV) have.
 Being able to estimate the impact of measures on youth unemployment to avoid social exclusion.
 Gaining more insight on how we can adjust our communication to different user groups so that we are more certain that the citizens get their benefits.
@@ -19,17 +21,20 @@ Enabling the teams to explore problems without being tied to a specified output
 Our ambition is to enable the teams to treat data in the same manner: as a product.
 
 ## The case for data governance
+
 The shift from building data pipelines answering specific questions to sharing data as products that can solve a variety of problems not yet known is massive.
 To make this leap, we look to the [data mesh-approach](https://martinfowler.com/articles/data-mesh-principles.html) described by Zhamakh Deghani.
 The principle of shifting ownership upstream to domain teams supported by a platform reducing the cognitive burden resonates with how we do it on the operational side.
 We firmly believe that the product teams are best positioned to produce data that meets the consumers` needs related to for instance business definitions and quality.
 On the other side, we acknowledge that there are justifications for collaborating with other teams on reaching decisions.
 A few of those are:
--	The need for coordination between teams. For instance, related to a common standard for communicating data quality
--	The need to make sure the teams´ internal decisions do not conflict with the “greater good” of NAV. Policies could for instance be applied to a data product with multiple critical dependencies downstream
--	The need to define policies related to compliance. GDPR is the prime example
+
+- The need for coordination between teams. For instance, related to a common standard for communicating data quality
+- The need to make sure the teams´ internal decisions do not conflict with the “greater good” of NAV. Policies could for instance be applied to a data product with multiple critical dependencies downstream
+- The need to define policies related to compliance. GDPR is the prime example
 
 ## Governance should not only control but enable.
+
 The word “governance” does not make people jump out of bed in the morning.
 Traditionally, governance has been focused more on making sure people don`t do stuff they should not do.
 Furthermore, data management – the management of business logic, access controls, etc. – has typically been the responsibility of a centralized team.
@@ -41,21 +46,24 @@ At the same time, the usage of data needs to adhere to the organization`s polici
 In other words, data governance should enable teams to a) produce data matching the analytical needs of NAV and b) stay compliant.
 
 ## Principles and representation
+
 The data mesh-paradigm describes a federated model of data governance.
 The actors on the platform need to collaborate on developing policies that provide value and are feasible.
 The data producers are supported by the data platform in performing the data management.
 At NAV, we have approached this by setting up a “ground rules forum”.
 The principles underlying the group`s work are:
-1.	The responsibility of producing data as a product should be placed as close to the origin as possible
-2.	Policies that move responsibility away from the data producers should be justified by value either in the form of analytical use or compliance
-3.	The policies should be supported by the platform when this is feasible
+
+1. The responsibility of producing data as a product should be placed as close to the origin as possible
+2. Policies that move responsibility away from the data producers should be justified by value either in the form of analytical use or compliance
+3. The policies should be supported by the platform when this is feasible
 
 The forum consists of team members with different perspectives:
--	Consumer: The value from an analytical perspective
--	Producer: The value from a producer`s perspective in addition to the cost of implementing policies
--	Platform: The knowledge of how the policies can be supported by the platform
--	Legal: The value in terms of compliance
--	Business owner: The overall business value
+
+- Consumer: The value from an analytical perspective
+- Producer: The value from a producer`s perspective in addition to the cost of implementing policies
+- Platform: The knowledge of how the policies can be supported by the platform
+- Legal: The value in terms of compliance
+- Business owner: The overall business value
 
 In a complex organization with close to 100 product teams, it is important to scope down the complexity.
 Luckily for us, NAV is currently replacing legacy systems.
@@ -65,29 +73,34 @@ The plan is to calibrate the organization and processes before scaling out to ot
 At the same time, we are also seeking input from other parts of the organization when forming policies.
 
 ## Governance affects everyone – and should include everyone!
+
 Broad involvement of the people sharing and using data is crucial for at least two reasons:
 It increases both the chance of forming better policies and the legitimacy of these policies.
 The process we have set up from start is deliberately simple:
-1.	People on the platform use Slack to discuss problems governance policies might solve
-2.	The forum discusses suggested policies when enough input has piled up. The suggested policies are documented using an architectural decision record
-3.	People on the platform share their opinions on the suggested policies
-4.	Decisions are reached
-5.	The policy is implemented, preferably supported by the platform.
+
+1. People on the platform use Slack to discuss problems governance policies might solve
+2. The forum discusses suggested policies when enough input has piled up. The suggested policies are documented using an architectural decision record
+3. People on the platform share their opinions on the suggested policies
+4. Decisions are reached
+5. The policy is implemented, preferably supported by the platform.
 
 Instead of engineering a complex process upfront, we start out with this and will calibrate it to fit our needs.
 
 ## How technology supports process
+
 We are currently working on a feature that illustrates how the implementation of policy can be supported by technology.
 To protect privacy, we have a policy that states that the consumer of data needs to document the legal basis for using the data.
 On our marketplace – where the producers share data the consumers can find and understand – we are now working on a feature where the consumers can fill out a form to request access.
 This feature is integrated with the databases where the legal basis is documented, easing the process for the consumer.
 The request is sent to the data product owner`s site on the marketplace, where they can grant/reject access.
 The policy was already there, but by adding the platform to the mix, we:
--	Eased the process for the consumer and the producer as the requests are now part of their workflow – not a Jira ticket completely on the side of everything
--	Eased the evaluation of assessments done by the consumers since we are logging it
--	Allowed for product thinking of this process. We can now set up metrics to see how long it takes for requests to be processed, the share of requests being rejected, etc. In turn, this can be used as input into the next iteration of the platform. This also covers the non-technical sides of the process: How can we change the policies to reduce frictions?
+
+- Eased the process for the consumer and the producer as the requests are now part of their workflow – not a Jira ticket completely on the side of everything
+- Eased the evaluation of assessments done by the consumers since we are logging it
+- Allowed for product thinking of this process. We can now set up metrics to see how long it takes for requests to be processed, the share of requests being rejected, etc. In turn, this can be used as input into the next iteration of the platform. This also covers the non-technical sides of the process: How can we change the policies to reduce frictions?
 
 ## Summing up
+
 Governance is key to unlocking the value of data in a secure way.
 To achieve this, we need to approach this by supporting teams instead of controlling them.
-The approach we describe here is intentionally lightweight, and we will share our learning points as we progress. 
+The approach we describe here is intentionally lightweight, and we will share our learning points as we progress.