fix: update links and remove .html extension

This commit is contained in:
Mathias Schopmans
2024-03-12 11:42:36 +01:00
committed by Mathias Schopmans
parent bc1e5b2d70
commit daa86a3f59
75 changed files with 103 additions and 103 deletions

View File

@@ -16,5 +16,5 @@ It handles things such as message resending in failure cases and preventing mess
Our first trials with Akka Streams were promising but we haven't yet implemented complex services with it.
We will continue looking into it together with the [Alpakka](/languages-and-frameworks/alpakka.html) Connectors for integration
We will continue looking into it together with the [Alpakka](/languages-and-frameworks/alpakka/) Connectors for integration
work.

View File

@@ -4,7 +4,7 @@ ring: assess
quadrant: languages-and-frameworks
---
When using [Akka Streams](/languages-and-frameworks/akka-streams.html) to build reactive data transformation services you usually need to connect to several services such as FTP, S3 buckets, AMQP brokers or different databases.
When using [Akka Streams](/languages-and-frameworks/akka-streams/) to build reactive data transformation services you usually need to connect to several services such as FTP, S3 buckets, AMQP brokers or different databases.
[Alpakka](https://developer.lightbend.com/docs/alpakka/current/) provides integration building blocks for Akka Streams to access these services in a reactive fashion and contains transformations for working with XML, CSV or JSON structured data.

View File

@@ -29,5 +29,5 @@ This is how we often conduct a CRC Session:
* Closing:
* We are often not too enthusiastic about adding a list of "collaborators" to the cards, since the sequence explains this very well.
* So just take a picture and document the result somewhere, so that you can review the status for the next CRC session.
* Maybe some decisions are worth being documented in your [Architecture decision records](/methods-and-patterns/adr.html)
* Maybe some decisions are worth being documented in your [Architecture decision records](/methods-and-patterns/adr/)

View File

@@ -9,5 +9,5 @@ Kubernetes has developed into the quasi-standard for container orchestration: Ne
We are running several production systems with Kubernetes and we are using it in concepts such as:
* "secrets" and "configmaps" to manage configurations for the applications. By updating these resources with an automated configuration pipeline you have a great method for configuration management.
* Autoscaling of Kubernetes nodes and the usage of "horizontal pod scaling" inside Kubernetes allows elastic scaling
* The support of managing permissions with OAuth allows you to secure Kubernetes with [Keycloak](/tools/keycloak.html) (SSO)
* The support of managing permissions with OAuth allows you to secure Kubernetes with [Keycloak](/tools/keycloak/) (SSO)
* Kubernetes extensibility and API can be used for automation and customization. There is a growing ecosystem around extensions, which adds additional features.

View File

@@ -11,6 +11,6 @@ Consumer Driven Contract testing is a pattern for testing interfaces/boundaries
It allows "consumers" to run tests against a defined Mock and record the defined interactions (=PACT).
It puts "providers" in the position to run the PACT tests inside their Continuous Integration Pipelines, so that the provider knows if he might break any consumers.
This approach makes sense in organisations where teams collaborate more closely (See [Strategic Domain Driven Design](/methods-and-patterns/strategic-domain-driven-design.html) ), e.g. to build [Microservice oriented architectures](/methods-and-patterns/microservices.html)
This approach makes sense in organisations where teams collaborate more closely (See [Strategic Domain Driven Design](/methods-and-patterns/strategic-domain-driven-design/) ), e.g. to build [Microservice oriented architectures](/methods-and-patterns/microservices/)
Consumer Driven Contract Testing and how it can be conducted with PACT is documented very nicely on the official PACT website: https://docs.pact.io/.

View File

@@ -15,4 +15,4 @@ There are various descriptions of what Reactive Programming actually is - at the
Under the term "Reactive Programming", we summarize the principles and implementations that underlie [ReactiveX](http://reactivex.io/) and the [Reactive Manifesto](https://www.reactivemanifesto.org/).
"Reactive Programming" is employed in many of our services frontend and backend but not always as an explicitly chosen pattern.
As different platforms have different means to tackle this style of programming, we choose to include "Reactive Programming" as a general Method and Patterns Item in addition to concrete libraries and APIs such as [Rx.JS](languages-and-frameworks/rxjs.html) or [Akka Streams](/languages-and-frameworks/akka-streams.html) to highlight the importance of the approach in general.
As different platforms have different means to tackle this style of programming, we choose to include "Reactive Programming" as a general Method and Patterns Item in addition to concrete libraries and APIs such as [Rx.JS](/languages-and-frameworks/rxjs/) or [Akka Streams](/languages-and-frameworks/akka-streams/) to highlight the importance of the approach in general.

View File

@@ -8,4 +8,4 @@ For the infrastructure of our OM3 projects we run multiple Kubernetes clusters,
Terraform allows us to easily manage our infrastructure, from AWS EC2 instances to RabbitMQ message queues.
Also, the Kops installer for Kubernetes on AWS uses Terraform as its main building brick, and we can trigger Kops via Terraform.
We bring terraform together with [Helm](/tools/helm.html) to manage similar parts of the infrastructure, for example a shared file with domain name to application mappings allows us to provision Route 53 DNS entries via Terraform and then roll out Kubernetes Ingress definitions with the appropriate hostname to service mapping via Helm.
We bring terraform together with [Helm](/platforms-and-aoe-services/helm/) to manage similar parts of the infrastructure, for example a shared file with domain name to application mappings allows us to provision Route 53 DNS entries via Terraform and then roll out Kubernetes Ingress definitions with the appropriate hostname to service mapping via Helm.