docs: fix internal links
This commit is contained in:
Stefan Rotsch
committed by
Stefan Rotsch
Stefan Rotsch
parent
014cc8d360
commit
84d5939770
@@ -6,4 +6,4 @@ tags: [devops]
|
||||
featured: false
|
||||
---
|
||||
|
||||
We have observed a decrease in our usage of Ansible recently. Our current focus lies more on immutable infrastructure using cloud providers. Nonetheless, Ansible still offers great benefits for mutable infrastructure that require support and is an excellent tool for achieving [Infrastructure as Code](../platforms-and-aoe-services/infrastructure-as-code.html) in such cases.
|
||||
We have observed a decrease in our usage of Ansible recently. Our current focus lies more on immutable infrastructure using cloud providers. Nonetheless, Ansible still offers great benefits for mutable infrastructure that require support and is an excellent tool for achieving [Infrastructure as Code](/platforms-and-aoe-services/infrastructure-as-code/) in such cases.
|
||||
|
||||
@@ -5,7 +5,7 @@ quadrant: platforms-and-aoe-services
|
||||
tags: [devops]
|
||||
---
|
||||
|
||||
We've previously used [AWS Fargate](../platforms-and-aoe-services/aws_fargate.html) when we didn't require full container orchestration and aimed for simplicity without managing the OS ourselves. When dealing with Azure projects, we searched for a similar solution. After exploring the somewhat opaque list of options for running Docker images on Azure, we decided on [Azure Container Instances](https://azure.microsoft.com/products/container-instances), as they appeared to align most closely with AWS Fargate in terms of simplicity.
|
||||
We've previously used [AWS Fargate](/platforms-and-aoe-services/aws_fargate/) when we didn't require full container orchestration and aimed for simplicity without managing the OS ourselves. When dealing with Azure projects, we searched for a similar solution. After exploring the somewhat opaque list of options for running Docker images on Azure, we decided on [Azure Container Instances](https://azure.microsoft.com/products/container-instances), as they appeared to align most closely with AWS Fargate in terms of simplicity.
|
||||
|
||||
However, while it's easy to get a container up and running with Azure Container Instances, it seems that this service is still in its early stages of maturity. Some notable limitations include the inability to automatically register containers in internal networks with Azure Application Gateway, a lack of support for internal DNS, occasional issues where containers need to be deleted and recreated instead of being smoothly replaced, and unexpected container restarts during the night without clear prior announcements or post-incident explanations.
|
||||
|
||||
|
||||
@@ -5,7 +5,7 @@ quadrant: methods-and-patterns
|
||||
tags: [coding, frontend]
|
||||
---
|
||||
|
||||
Since the release of React 18, many CSS-in-JS libraries like styled-components, emotion, and stitches have encountered a significant challenge. They generate CSS only at runtime, making them incompatible with streaming and [React Server Components](../methods-and-patterns/react-server-components.html). React developers have addressed this issue in an [article](https://github.com/reactwg/react-18/discussions/110), where they explicitly advise against using CSS-in-JS libraries that generate CSS at runtime.
|
||||
Since the release of React 18, many CSS-in-JS libraries like styled-components, emotion, and stitches have encountered a significant challenge. They generate CSS only at runtime, making them incompatible with streaming and [React Server Components](/methods-and-patterns/react-server-components/). React developers have addressed this issue in an [article](https://github.com/reactwg/react-18/discussions/110), where they explicitly advise against using CSS-in-JS libraries that generate CSS at runtime.
|
||||
|
||||
This has created substantial uncertainty among developers and the communities of these affected libraries. The question arises: Is it possible to refactor these runtime libraries into buildtime libraries? To date, none of the libraries have announced any such plans, and, unfortunately, one of the most popular new libraries, stitches, is [no longer being maintained](https://github.com/stitchesjs/stitches/discussions/1149#discussioncomment-6223090).
|
||||
|
||||
|
||||
@@ -6,4 +6,4 @@ tags: [devops]
|
||||
featured: false
|
||||
---
|
||||
|
||||
We've faded out Kubernetes Operators as a standalone recommendation because they are such a central part of [Kubernetes](../platforms-and-aoe-services/kubernetes.html) that their use appears self-evident.
|
||||
We've faded out Kubernetes Operators as a standalone recommendation because they are such a central part of [Kubernetes](/platforms-and-aoe-services/kubernetes/) that their use appears self-evident.
|
||||
|
||||
@@ -5,7 +5,7 @@ quadrant: platforms-and-aoe-services
|
||||
tags: [devops]
|
||||
---
|
||||
|
||||
After having very positive experiences, we decided to replace our [ELK stacks](../platforms-and-aoe-services/elk-stack.html) with Loki, primarily for the following reasons:
|
||||
After having very positive experiences, we decided to replace our [ELK stacks](/platforms-and-aoe-services/elk-stack/) with Loki, primarily for the following reasons:
|
||||
|
||||
- Loki is significantly more cost-effective than the storage requirements of Elasticsearch.
|
||||
- The PromQL-like query language, familiar to users of Prometheus, makes it easier for DevOps and SRE teams who already use Prometheus for monitoring to work with logs.
|
||||
|
||||
@@ -6,4 +6,4 @@ tags: [security, architecture]
|
||||
featured: false
|
||||
---
|
||||
|
||||
We have been transitioning away from using Open Policy Agent at AOE. For alternative solutions, please refer to [Policy as Code](../methods-and-patterns/policy-as-code.html).
|
||||
We have been transitioning away from using Open Policy Agent at AOE. For alternative solutions, please refer to [Policy as Code](/methods-and-patterns/policy-as-code/).
|
||||
|
||||
Reference in New Issue
Block a user