[ES] Update term reference links (#2353)

jossemarGT · web-flow · commit 996973bff450 · 2023-09-05T11:52:23.000-06:00
Since not all the glossary terms were available at the same time,
contributors deferred from referencing terms in Spanish. Now, that
we have the majority of terms translated we need to double check
we are using the correct references.

For the record, this can be easily spotted with the following grep
expression:

  grep -PHnro "\[.*?\].*?\(/.*?\)" content/es | grep -v '(/es/'

It will capture and display all the reference links that are not
using the Spanish terms.

PS: I omitted SaaS since it got deprecated and its removal was
already done in the main branch.

Signed-off-by: Jonnatan Jossemar Cordero &lt;jossemargt@gmail.com&gt;
diff --git a/content/es/auto-scaling.md b/content/es/auto-scaling.md
@@ -5,7 +5,7 @@ category: Propiedad
 tags: ["infrastructure", "", ""]
 ---
 
-El autoescalado es la habilidad de un sistema para [escalar](/scalability) automáticamente, en términos de recursos computacionales.
+El autoescalado es la habilidad de un sistema para [escalar](/es/scalability) automáticamente, en términos de recursos computacionales.
 Con un sistema de autoescalado, los recursos son agregados automáticamente cuando se necesitan y pueden escalar para cumplir con la demanda fluctuante de los usuarios.
 El proceso de autoescalado varía y es configurable para escalar basado en diferentes métricas, como son la memoria o el uso de CPU.
 Los servicios gestionados en la nube son los que están asociados típicamente con esta funcionalidad de autoescalado
@@ -15,7 +15,7 @@ Anteriormente, la infraestructura y las aplicaciones eran diseñadas para consid
 Esta arquitectura implicaba que había más recursos que eran desaprovechados o con cambios rígidos frente a la demanda de los usuarios.
 La rigidez en este caso, incrementa el coste y puede suponer una pérdida de negocios debido a problemas de capacidad.
 
-Aprovechando la nube, la [virtualización](/virtualization) y la [contenerización](/es/containerization/) de aplicaciones y sus dependencias,
+Aprovechando la nube, la [virtualización](/es/virtualization) y la [contenerización](/es/containerization/) de aplicaciones y sus dependencias,
 las organizaciones pueden construir aplicaciones que escalan de manera acorde a la demanda de los usuarios.
 Se pueden monitorear la demanda de las aplicaciones y de manera automática escalar las mismas, proporcionando una experiencia al usuario final óptima.
 Tomemos el ejemplo del aumento de la audiencia de Netflix todos los viernes por la noche.
diff --git a/content/es/bare-metal-machine.md b/content/es/bare-metal-machine.md
@@ -11,7 +11,7 @@ Bare metal se refiere a una computadora física, más específicamente un servid
 La distinción es importante en la informática moderna porque muchos, si no es que la mayoría, de los servidores son [máquinas virtuales](/es/virtual-machine/).
 Un servidor físico suele ser una computadora bastante grande con un potente hardware incorporado.
 La instalación de un sistema operativo y la ejecución de aplicaciones directamente en ese hardware físico,
-sin [virtualización](/virtualization/), se conoce como ejecución "bare metal".
+sin [virtualización](/es/virtualization/), se conoce como ejecución "bare metal".
 
 ## Problema que aborda
 
@@ -29,6 +29,6 @@ bare metal puede ser la solución adecuada.
 En el contexto de las [aplicaciones nativas para la nube](/es/cloud-native-apps/),
 generalmente pensamos en el rendimiento en términos de [escalabilidad](/es/scalability/) para una gran cantidad de eventos simultáneos,
 que pueden mitigarse mediante el [escalado horizontal](/es/horizontal-scaling/) (agregando más máquinas a su grupo de recursos).
-Sin embargo, algunas cargas de trabajo pueden requerir [escalado vertical](/vertical-scaling/) (agregar más potencia a una máquina física existente)
+Sin embargo, algunas cargas de trabajo pueden requerir [escalado vertical](/es/vertical-scaling/) (agregar más potencia a una máquina física existente)
 y/o una respuesta extremadamente rápida de hardware físico, en cuyo caso se adapta mejor el bare metal.
 Bare metal también le permite ajustar el hardware físico y posiblemente incluso los controladores de hardware para ayudarlo a realizar su tarea.
diff --git a/content/es/cloud-computing.md b/content/es/cloud-computing.md
@@ -23,5 +23,5 @@ La computación en la nube permite a las organizaciones subcontratar una parte d
 
 Los proveedores de la nube ofrecen a las organizaciones la capacidad de alquilar recursos informáticos bajo demanda y pagar por el uso.
 Esto permite dos innovaciones principales:
-las organizaciones pueden probar cosas sin perder tiempo planificando y gastando dinero o recursos en nueva infraestructura física y pueden [escalar](/scalability/) según sea necesario y bajo demanda.
+las organizaciones pueden probar cosas sin perder tiempo planificando y gastando dinero o recursos en nueva infraestructura física y pueden [escalar](/es/scalability/) según sea necesario y bajo demanda.
 La computación en la nube permite a las organizaciones adoptar tanta o tan poca infraestructura como necesiten.
diff --git a/content/es/cloud-native-apps.md b/content/es/cloud-native-apps.md
@@ -9,15 +9,15 @@ tags: ["application", "fundamental", ""]
 
 Las aplicaciones nativas para la nube están diseñadas específicamente para aprovechar las innovaciones en [computación en la nube](/es/cloud_computing/).
 Estas aplicaciones se integran fácilmente con sus respectivas arquitecturas en la nube,
-aprovechando los recursos de la nube y las capacidades de [escalado](/scalability/).
+aprovechando los recursos de la nube y las capacidades de [escalado](/es/scalability/).
 También se refiere a las aplicaciones que aprovechan las innovaciones en infraestructura impulsadas por la computación en la nube.
 Las aplicaciones nativas para la nube de hoy en día incluyen aplicaciones que se ejecutan en el centro de datos de un proveedor de la nube y en plataformas nativas de la nube on-premises.
 
 ## Problema que aborda
 
 Tradicionalmente, los entornos on-premises proporcionaban recursos informáticos de una manera bastante personalizada.
-Cada centro de datos tenía servicios que [acoplaban estrechamente](/tightly-coupled-architectures/) aplicaciones a entornos específicos,
-a menudo dependiendo en gran medida del aprovisionamiento manual de infraestructura, como [máquinas virtuales](/virtual_machine/) y servicios.
+Cada centro de datos tenía servicios que [acoplaban estrechamente](/es/tightly-coupled-architectures/) aplicaciones a entornos específicos,
+a menudo dependiendo en gran medida del aprovisionamiento manual de infraestructura, como [máquinas virtuales](/es/virtual-machine/) y servicios.
 Esto, a su vez, restringió a los desarrolladores y sus aplicaciones a ese centro de datos en específico.
 Las aplicaciones que no fueron diseñadas para la nube no pudieron aprovechar las capacidades de resiliencia y escalabilidad de un entorno de nube.
 Por ejemplo, las aplicaciones que requieren una intervención manual para iniciarse correctamente no pueden escalarse automáticamente,
diff --git a/content/es/container-image.md b/content/es/container-image.md
@@ -21,10 +21,10 @@ Cualquier configuración errónea entre los entornos es problemática, a menudo
 Un entorno de aplicación tiene que ser fácil de replicar, además de estar bien definido;
 en caso contrario, la posibilidad de bugs y errores relacionados con el entorno aumenta.
 Cuando los entornos de aplicación no están configurados de manera adecuada o son inexactos,
-el escalado [horizontal](/es/horizontal-scaling/) y [vertical](/vertical-scaling/) de las aplicaciones se complica y reduce su efectividad.
+el escalado [horizontal](/es/horizontal-scaling/) y [vertical](/es/vertical-scaling/) de las aplicaciones se complica y reduce su efectividad.
 
 ## ¿Cómo ayuda?
 
 Las imágenes empaquetan una aplicación con todas las dependencias necesarias para ejecutarse, como el servidor de aplicación.
 Esto otorga consistencia en todos los entornos, incluyendo los dispositivos locales de desarrollo.
-Una imagen puede dar lugar a cualquier número de contenedores, según sea necesario, permitiendo una mayor [escalabilidad](/scalability/).
+Una imagen puede dar lugar a cualquier número de contenedores, según sea necesario, permitiendo una mayor [escalabilidad](/es/scalability/).
diff --git a/content/es/continuous-delivery.md b/content/es/continuous-delivery.md
@@ -34,4 +34,4 @@ Por lo general, el desarrollo basado en troncos (trunk-based development) se usa
 ## Términos relacionados
 
 * [Integración Continua](/es/continuous-integration/)
-* [Despliegue Continuo](/continuous_deployment/)
+* [Despliegue Continuo](/es/continuous-deployment/)
diff --git a/content/es/devops.md b/content/es/devops.md
@@ -13,7 +13,7 @@ DevOps requiere grupos de ingenieros que trabajen en componentes pequeños (en l
 
 ## Problema que aborda
 
-Tradicionalmente, en organizaciones complejas con [aplicaciones monolíticas](/es/monolithic-apps/) con arquitecturas [estrechamente acopladas](/tightly-coupled-architectures/),
+Tradicionalmente, en organizaciones complejas con [aplicaciones monolíticas](/es/monolithic-apps/) con arquitecturas [estrechamente acopladas](/es/tightly-coupled-architectures/),
 el trabajo generalmente se distribuía entre varios equipos.
 Esta fragmentación del desarrollo dio lugar a numerosos traspasos y largos plazos de entrega.
 Cada vez que un componente o alguna actualización estaba lista, se colocaba en una cola para el siguiente equipo.
diff --git a/content/es/horizontal-scaling.md b/content/es/horizontal-scaling.md
@@ -8,7 +8,7 @@ tags: ["infrastructure", "", ""]
 ## ¿Qué es?
 
 Escalado horizontal es una técnica donde la capacidad del sistema es incrementada agregando más [nodos](/es/nodes)
-en vez de agregar más recursos computacionales a nodos individuales (conocido como [escalado vertical](/vertical-scaling/)).
+en vez de agregar más recursos computacionales a nodos individuales (conocido como [escalado vertical](/es/vertical-scaling/)).
 Como ejemplo, digamos que tenemos un sistema con 4 GB de memoria y queremos incrementar su capacidad a 16 GB,
 escalar horizontalmente significa agregar 4 x 4 GB en vez de cambiar a un sistema de 16 GB.
 
@@ -20,7 +20,7 @@ en vez de expandir la capacidad de cada uno individualmente.
 ## Problema que aborda
 
 Cuando la demanda a una aplicación crece más allá de la capacidad de la misma y de su instancia,
-necesitamos encontrar una manera de [escalar](/scale) (agregar capacidad) al sistema.
+necesitamos encontrar una manera de [escalar](/es/scalability/) (agregar capacidad) al sistema.
 Podemos hacerlo agregando más nodos al sistema (escalado horizontal)
 o más recursos computacionales a los nodos existentes (escalado vertical).
 
diff --git a/content/es/hypervisor.md b/content/es/hypervisor.md
@@ -7,10 +7,10 @@ tags: ["application", "", ""]
 
 ## ¿Qué es?
 
-Un hipervisor utiliza el concepto de [virtualización](/virtualization/)
+Un hipervisor utiliza el concepto de [virtualización](/es/virtualization/)
 aprovechando los recursos de la llamada [máquina bare metal](/es/bare-metal-machine/)
 (CPU, memoria, recursos de red, y almacenamiento), dividiéndolos en partes más pequeñas,
-y ubicando recursos suficientes para crear [máquinas virtuales](/virtual-machine/)
+y ubicando recursos suficientes para crear [máquinas virtuales](/es/virtual-machine/)
 hasta que el servidor base alcanza su límite de funcionamiento.
 
 ## Problema que aborda
diff --git a/content/es/immutable-infrastructure.md b/content/es/immutable-infrastructure.md
@@ -6,7 +6,7 @@ tags: ["infrastructure", "property", ""]
 ---
 
 Infraestructura inmutable se refiere a la infraestructura informática
-([máquinas virtuales](/virtual-machine/), [contenedores](/es/container/), dispositivos de red)
+([máquinas virtuales](/es/virtual-machine/), [contenedores](/es/container/), dispositivos de red)
 que no se puede cambiar una vez implementada.
 Esto se puede hacer cumplir mediante un proceso automatizado que sobreescriba los cambios no autorizados o
 a través de un sistema que no permita cambios en primer lugar.
diff --git a/content/es/infrastructure-as-a-service.md b/content/es/infrastructure-as-a-service.md
@@ -8,7 +8,7 @@ tags: ["infrastructure", "", ""]
 ## ¿Qué es?
 
 Infraestructura como Servicio, o IaaS, es un modelo de servicio de [computación en la nube](/es/cloud_computing/) que
-ofrece recursos de cómputo, almacenamiento y red mediante servidores [físicos](/es/bare_metal_machine/) o [virtualizados](/virtualization/)
+ofrece recursos de cómputo, almacenamiento y red mediante servidores [físicos](/es/bare_metal_machine/) o [virtualizados](/es/virtualization/)
 suministrados bajo demanda en un modelo de pago por uso.
 Los proveedores de la nube poseen y operan el hardware y el software,
 a disposición de los consumidores en despliegues de nube pública, privada o híbrida.
diff --git a/content/es/infrastructure-as-code.md b/content/es/infrastructure-as-code.md
@@ -14,13 +14,13 @@ por lo general usando scripts con la consola u otras herramientas de configuraci
 ## Problema que aborda
 
 Construir aplicaciones de forma nativa para la nube requiere que la infraestructura sea desechable y reproducible.
-Además requiere [escalar](/scalability/) bajo demanda de forma automática y repetible, potencialmente sin la intervención humana.
+Además requiere [escalar](/es/scalability/) bajo demanda de forma automática y repetible, potencialmente sin la intervención humana.
 El aprovisionamiento manual no puede cumplir los requerimientos de respuesta y escalado de las [aplicaciones nativas para la nube](/es/cloud-native-apps/).
 Los cambios manuales no son reproducibles, rápidamente se enfrentan a limites de escalabilidad, e introducen errores de configuración.
 
 ## ¿Cómo ayuda?
 
-Representados los recursos del [centro de datos](/data-center/) tales como servidores, balanceadores de carga y sub-redes como código,
+Representados los recursos del [centro de datos](/es/data-center/) tales como servidores, balanceadores de carga y sub-redes como código,
 les permite a los equipos de infraestructura poseer una fuente única de verdad para todas las configuraciones y
-también les permite administrar sus [centro de datos](/data-center/) en flujos de [CI](/es/continuous-integration/)/[CD](/es/continuous-delivery/)
+también les permite administrar sus [centro de datos](/es/data-center/) en flujos de [CI](/es/continuous-integration/)/[CD](/es/continuous-delivery/)
 implementando un sistema de control de versiones y estrategias de despliegue.
diff --git a/content/es/kubernetes.md b/content/es/kubernetes.md
@@ -23,7 +23,7 @@ La demanda de recursos de cómputo incrementa día con día y las organizaciones
 ## ¿Cómo ayuda?
 
 De manera parecida a las herramientas tradicionales de [infraestructura como código](/es/infrastructure-as-code/), Kubernetes ayuda con la automatización pero tiene la ventaja de trabajar con contenedores.
-Los contenedores son más resistentes a fallas por diferencias en entornos a comparación con las [máquinas virtuales](/virtual-machine/) o físicas.
+Los contenedores son más resistentes a fallas por diferencias en entornos a comparación con las [máquinas virtuales](/es/virtual-machine/) o físicas.
 
 Aún más, Kubernetes funciona declarativamente, lo que significa que, en lugar de que los operadores proporcionen las instrucciones sobre cómo realizar una acción, ellos describen, por lo general en archivos de manifiesto (por ejemplo, YAML), lo que quieren que se logre;
 Kubernetes se encargará del "cómo" por sí mismo.
diff --git a/content/es/loosely-coupled-architecture.md b/content/es/loosely-coupled-architecture.md
@@ -7,7 +7,7 @@ tags: ["fundamental", "architecture", "property"]
 
 
 La arquitectura débilmente acoplada es un tipo de arquitectura en donde los componentes individuales de una aplicación se construyen de manera independiente unos de los otros 
-(es el paradigma opuesto a la [arquitectura fuertemente acoplada](/tightly-coupled-architectures/)). 
+(es el paradigma opuesto a la [arquitectura fuertemente acoplada](/es/tightly-coupled-architectures/)). 
 Cada componente, a veces denominado [microservicio](/es/microservices/), 
 está diseñado para realizar una función específica de manera que pueda ser utilizado por cualquier número de servicios. 
 Este patrón es generalmente más lento de implementar que la arquitectura estrechamente acoplada, 
diff --git a/content/es/microservices-architecture.md b/content/es/microservices-architecture.md
@@ -24,7 +24,7 @@ El aumento de suscripciones exige más capacidad de suscripción.
 Tradicionalmente (enfoque monolítico), toda la aplicación tendría que ser [escalada](/es/scalability/) para acomodar el aumento - un uso muy ineficiente de los recursos.
 
 Las arquitecturas monolíticas también hacen que los desarrolladores tengan la posibilidad de caer en errores del diseño.
-Como todo el código está en el mismo sitio, es más fácil hacer que ese código esté [estrechamente acoplado](/tightly-coupled-architectures/) y más difícil aplicar el principio de separación de preocupaciones.
+Como todo el código está en el mismo sitio, es más fácil hacer que ese código esté [estrechamente acoplado](/es/tightly-coupled-architectures/) y más difícil aplicar el principio de separación de preocupaciones.
 Los monolitos también suelen requerir que los desarrolladores entiendan todo el código base antes de desplegar cualquier funcionalidad.
 La arquitectura de microservicios es una respuesta a estos retos.
 
diff --git a/content/es/mutual-transport-layer-security.md b/content/es/mutual-transport-layer-security.md
@@ -7,7 +7,7 @@ tags: ["security", "networking", ""]
 
 ## ¿Qué es?
 
-La seguridad mutua de capa de transporte (mTLS en Inglés) es una técnica utilizada para autenticar y codificar mensajes enviados entre dos [servicios](/service).
+La seguridad mutua de capa de transporte (mTLS en Inglés) es una técnica utilizada para autenticar y codificar mensajes enviados entre dos [servicios](/es/service).
 mTLS es el protocolo de [Seguridad de capa de transporte](/es/transport-layer-security/) (TLS) estándar pero,
 en vez de validar la identidad de solo una conexión, se validan ambos lados.
 
diff --git a/content/es/nodes.md b/content/es/nodes.md
@@ -11,7 +11,7 @@ Un nodo es un servidor que trabaja en conjunto a otros servidores, o nodos, para
 Toma tu laptop, el módem y la impresora como ejemplo.
 Están conectados a través de tu red wifi comunicándose y colaborando, cada uno representa un nodo.
 En [computación en la nube](/es/cloud-computing/), un nodo puede ser un servidor físico,
-un servidor virtual, denominado [VM](/virtual-machine/), o incluso un [contenedor](/es/container/).
+un servidor virtual, denominado [VM](/es/virtual-machine/), o incluso un [contenedor](/es/container/).
 
 ## Problema que aborda
 
diff --git a/content/es/platform-as-a-service.md b/content/es/platform-as-a-service.md
@@ -15,7 +15,7 @@ Heroku, Cloud Foundry y App Engine son ejemplos de ofertas de PaaS.
 Para aprovechar los patrones de las aplicaciones nativas para la nube como son los [microservicios](/es/microservices/) o las [aplicaciones distribuidas](/es/distributed-apps/),
 los equipos de operaciones y los desarrolladores necesitan ser capaces de descargar un tiempo significativo de trabajo en operaciones y mantenimiento.
 Estos incluyen tareas como el aprovisionamiento de infraestructura,
-el manejo del [descubrimiento de servicios](/service-discovery/) y balanceo de cargas, y [escalamiento](/scalability/) de aplicaciones.
+el manejo del [descubrimiento de servicios](/es/service-discovery/) y balanceo de cargas, y [escalamiento](/es/scalability/) de aplicaciones.
 
 ## ¿Cómo ayuda?
 
diff --git a/content/es/scalability.md b/content/es/scalability.md
@@ -16,6 +16,6 @@ y ¿cuántos registros y operaciones puede soportar el plano de control?
 Un sistema escalable facilita agregar más capacidad.
 Diferenciamos entre dos enfoques de escala.
 Por un lado, está el [escalado horizontal](/es/horizontal-scaling/) que agrega más nodos para manejar una mayor carga.
-Por el contrario, en el [escalado vertical](/vertical-scaling/) los nodos individuales se vuelven más poderosos para realizar más transacciones
+Por el contrario, en el [escalado vertical](/es/vertical-scaling/) los nodos individuales se vuelven más poderosos para realizar más transacciones
 (por ejemplo, agregando más memoria o CPU a una máquina individual).
 Un sistema escalable es capaz de cambiar fácilmente y satisfacer las necesidades del usuario.
diff --git a/content/es/stateful-apps.md b/content/es/stateful-apps.md
@@ -7,7 +7,7 @@ tags: ["fundamental", "application", ""]
 
 ## ¿Qué es?
 
-Cuando hablamos de aplicaciones con estado (y [sin estado](/stateless-apps/)),
+Cuando hablamos de aplicaciones con estado (y [sin estado](/es/stateless-apps/)),
 éste estado se refiere a cualquier dato que la aplicación necesita almacenar para funcionar.
 Por ejemplo, cualquier tipo de tienda en línea que recuerda tu carro de compras es una aplicación con estado.
 
diff --git a/content/es/style-guide/_index.md b/content/es/style-guide/_index.md
@@ -159,7 +159,7 @@ Cuando corresponda, use **ejemplos del mundo real** que ayuden a los lectores (e
 
 Cuando se use en su definición, siempre **enlace a los términos existentes del glosario** (solo la primera mención debe tener un hipervínculo).
 
-**Ejemplo**: eche un vistazo a la sección "Qué es" de la [definición de service mesh](/service-mesh/).
+**Ejemplo**: eche un vistazo a la sección "Qué es" de la [definición de service mesh](/es/service-mesh/).
 Se vincula con las definiciones de microservicios, servicio, fiabilidad y observabilidad.
 Además, utiliza un ejemplo del mundo real que compara los desafíos de la red en un entorno de microservicios
 (algo con lo que las personas no técnicas no pueden relacionarse) con los problemas de wifi (algo que cualquiera que use una computadora portátil puede entender).
