DEV Community: Nicolás A. Georger

kgateway: An amazing tool to simplify traffic management using Kubernetes API Gateway

Nicolás A. Georger — Mon, 24 Mar 2025 07:28:42 +0000

Kgateway is a feature-rich, fast, and flexible Kubernetes-native ingress controller and next-generation API gateway. Built on top of the robust Envoy proxy and the Kubernetes Gateway API, Kgateway acts as a reverse proxy, providing a crucial security barrier between your clients and the microservices that constitute your application. Think of it as the bouncer at the club, but instead of checking IDs, it verifies and routes requests to the appropriate microservice.

Kgateway's Superpowers

Kgateway isn't just another API gateway; it's fully compliant with the Kubernetes Gateway API and extends its functionality with custom Gateway APIs like RoutePolicies, ListenerPolicies, and Backends. These resources allow for centralized configuration of advanced traffic management, security, and resiliency rules for an HTTPRoute or Gateway listener. In simpler terms, Kgateway gives you more control and flexibility over how traffic flows through your Kubernetes cluster.

Extensions and integrations

The kgateway project offers a range of extensions on top of the Kubernetes Gateway API, enabling advanced routing, security, and resiliency capabilities. Some of these extensions include:

Access logging Security: Keep tabs on who's accessing what.
AWS ALB and NLB Traffic: Seamlessly integrate with AWS load balancers.
AWS Lambda Traffic: Route traffic to serverless functions.
Buffering Traffic: Manage traffic spikes like a pro.
Delegation Traffic: Delegate routing decisions for more granular control.
Direct responses Traffic: Send direct responses without hitting a backend.
Gateway customization Setup: Tailor the gateway to your specific needs.
Integrations Setup: Integrate with other tools and services.
Mirroring Resiliency: Mirror traffic for testing and debugging.
Transformations Traffic: Modify requests and responses on the fly.

Default Gateway Proxy Setup: The Magic Behind the Scenes

When you create a Kubernetes Gateway resource, Kgateway automatically spins up, bootstraps, and manages gateway proxy deployments. This magic is achieved through a combination of Kgateway and Kubernetes resources, including GatewayClass, GatewayParameters, and a gateway proxy template that includes the Envoy configuration for each proxy.

For a deeper dive into the default setup and how these resources interact, check out the Default gateway proxy setup.

Example of a GatewayClass:

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: kgateway
spec:
  controllerName: kgateway.dev/kgateway
  description: KGateway Controller
  parametersRef:
    group: gateway.kgateway.dev
    kind: GatewayParameters
    name: kgateway
    namespace: kgateway-system

Deployment Patterns: Choose how to route your traffic

Kgateway's flexibility allows you to deploy it in a way that best suits your environment. Here are some recommended deployment patterns:

Simple Ingress: The Classic Approach

In this setup, a single Kgateway proxy serves as the ingress API gateway for all workloads in a Kubernetes cluster. It's centrally managed by the Kgateway control plane and configured to match and forward traffic based on your defined rules. This is a great starting point for smaller environments where all workloads run in a single cluster.

Sharded Gateway: Divide and Conquer

For larger environments or those with both high and low traffic services, a sharded gateway can help isolate services and protect against noisy neighbors. Multiple gateway proxies split the traffic for different services, providing better load balancing and isolation.

Sharded Gateway with Central Ingress: The Best of Both Worlds

This pattern combines a central ingress gateway proxy with a second layer of sharded gateway proxies. The central gateway applies common traffic management, resiliency, and security rules, while the second layer handles traffic for specific apps, teams, or namespaces. This is ideal if you need a central IP address and DNS name for the gateway that serves all your traffic.

Kgateway can also be paired with other proxy types, such as HAProxy or AWS NLB/ALB, as your central ingress endpoint.

API Gateway for a Service Mesh: Istio Ambient Mesh Integration

Kgateway can be deployed as an ingress, egress, or waypoint proxy gateway for workloads in an Istio ambient mesh. This allows you to leverage Kgateway's features within your service mesh environment.

For more details, refer to the guides for using Kgateway as an ingress or waypoint proxy for your ambient mesh.

Kubernetes Gateway API Success with kgateway

Kgateway is a powerful and versatile tool for managing traffic in your Kubernetes environment. Whether you're running a small cluster or a large, complex infrastructure, Kgateway provides the features and flexibility you need to ensure secure, reliable, and efficient communication between your services. So, go ahead and give Kgateway a try – your microservices will thank you!

Learn more

[

kgateway

Kgateway is a feature-rich, fast, and flexible API gateway that is built on top of Envoy proxy and the Kubernetes Gateway API. It excels in function-level routing, supports legacy apps, microservices and serverless, offers robust discovery capabilities, integrates seamlessly with open-source projects, and is designed to support hybrid applications with various technologies, architectures, protocols, and clouds.

](https://kgateway.dev/?ref=sredevops.org)

[

Welcome

](https://kgateway.dev/docs/?ref=sredevops.org)

Kiss Goodbye to QEMU: Unleash the Power of Native GitHub Runners for Multi-Arch Docker Images

Nicolás A. Georger — Tue, 18 Mar 2025 10:01:46 +0000

In the cutthroat world of DevOps, where speed and efficiency are the holy grail, building multi-architecture Docker images used to be a pain in the neck. But hold on tight! With the advent of native GitHub runners, you can finally ditch the quirky QEMU emulation and embrace the lightning speed of native builds. This guide will take you by the hand and lead you through the dark arts of setting up a multi-architecture build process using GitHub Actions.

[

GitHub - sredevopsorg/multi-arch-docker-github-workflow: How to build a Multi-Architecture Docker Image in Github Actions using multiple runners without QEMU

How to build a Multi-Architecture Docker Image in Github Actions using multiple runners without QEMU - sredevopsorg/multi-arch-docker-github-workflow

GitHubsredevopsorg

](https://github.com/sredevopsorg/multi-arch-docker-github-workflow?ref=sredevops.org)

Overview: The Two-Headed Beast

This workflow is like a two-headed beast, split into two main jobs:

Build Job: The Workhorse

Matrix Strategy: This bad boy builds images for each platform separately, like a well-oiled machine.
Docker Context and Buildx Setup: Configures the native builds, so you don't have to mess with QEMU.
GHCR Login and Push: Uploads the image by its unique digest, keeping things tidy.
Artifact Export: Saves the digest for later use, because we're smart like that.

Merge Job: The Brain

Digest Download: Retrieves the digests from the build job, like a detective gathering clues.
Metadata Generation: Ensures consistency with the built images, because we like things neat.
Multi-Arch Manifest Creation: Combines the images into a single, powerful manifest.
Manifest Push: Uploads everything to GHCR, enabling Docker to magically select the correct image based on architecture.

This two-step process results in a "fat" image – a monstrous creation that delivers the right binary for any user's architecture, no questions asked.

Features: The Cool Stuff

Native Builds: We're using GitHub's native runners, so say adios to QEMU and its shenanigans.
Multi-Arch Manifest: Merges per-architecture images into one, because we're efficient like that.
Build Caching: Speeds up subsequent builds, because who has time to wait?
OCI Metadata: Enhances image provenance with labels and annotations, making your images look professional.
Concurrency Control: Cancels outdated builds using GitHub Actions concurrency, keeping things clean and tidy.

Getting Started: Let's Roll Up Our Sleeves

Prerequisites: What You Need

A GitHub public repository (because the arm64 runners are picky and only work with public repos).
A valid Dockerfile in the repository root, ready to be built.

Setup: The Nitty-Gritty

Fork the Repository and edit the multi-build.yaml file.
Review and Customize:
- Dockerfile: Tweak it to suit your application's dark desires.
- Workflow File: Adjust the parameters in .github/workflows/multi-build.yaml as needed.

A Step-by-Step Detailed Explanation: The Gory Details

File: multi-build.yaml

Let's dissect this beast, shall we?

name: Build multi arch Docker Image with separate Github Runners

on:
  workflow_dispatch:
  push:
    branches:
      - main
    paths:
      - 'Dockerfile'
      - '.github/workflows/multi-build.yaml'
env:
  GHCR_IMAGE: ghcr.io/${{ github.repository }}
#(...)

This workflow is a masterpiece that builds a multi-arch Docker image using GitHub Actions. It leverages separated GitHub Runners with native support for ARM64 and AMD64 architectures, completely avoiding the dreaded QEMU emulation.
It uses Docker Buildx, a powerful tool, to build and push the image to the GitHub Container Registry (GHCR).
GHCR_IMAGE: Defines the name of the Docker image to be built and pushed to GHCR. The image name is cleverly derived from the GitHub repository name and the GHCR URL, resulting in a format like ghcr.io/owner/repo.

# (...)

permissions:
  contents: read
concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true
#(...)

permissions: Sets global permissions for the workflow. These can be overridden at the job level if needed.
concurrency: This ensures that only one job in the group runs at a time. If a new job is triggered, the previous one is mercilessly canceled.

# (...)

jobs:
  build:
    strategy:
      fail-fast: false
      matrix:
        platform:
          - linux/amd64
          - linux/arm64
    permissions:
      attestations: write
      actions: read
      checks: write
      contents: write
      deployments: none
      id-token: write
      issues: read
      discussions: read
      packages: write
      pages: none
      pull-requests: read
      repository-projects: read
      security-events: read
      statuses: read
#(...)

build: This job is the workhorse, building the Docker image for each platform specified in the matrix.
matrix: Defines the platforms: linux/amd64 and linux/arm64. The build job will run for each of these platforms.
permissions: Sets specific permissions for the build job, allowing it to write to GHCR and read from the repository.

# (...)

    runs-on: ${{ matrix.platform == 'linux/amd64' && 'ubuntu-latest' || matrix.platform == 'linux/arm64' && 'ubuntu-24.04-arm' }}
#(...)

runs-on: This cleverly selects the appropriate runner based on the platform:
- For linux/amd64, it uses the latest Ubuntu runner.
- For linux/arm64, it uses an Ubuntu 24.04 ARM runner.

# (...)

    name: Build Docker image for ${{ matrix.platform }}
    steps:
      -
        name: Prepare environment for current platform 
        id: prepare
        run: |
          platform=${{ matrix.platform }}
          echo "PLATFORM_PAIR=${platform//\//-}" >> $GITHUB_ENV

      - name: Checkout
        uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2

      - name: Docker meta default
        id: meta
        uses: docker/metadata-action@902fa8ec7d6ecbf8d84d538b9b233a880e428804 # v5.7.0
        with:
          images: ${{ env.GHCR_IMAGE }}
#(...)

The prepare step sets up the environment for the current platform. It replaces '/' in the platform name with '-' and sets it as an environment variable (PLATFORM_PAIR). This is useful for naming artifacts and other resources that can't handle '/'.
Checkout: This step uses actions/checkout@v4.2.2 to clone the repository into the runner's workspace.
Docker meta default: This step uses docker/metadata-action@v5.7.0 to generate metadata for the Docker image, including the image name, tags, and labels. This metadata will be used later for building and pushing the image.

# (...)

      - name: Set up Docker Context for Buildx

        id: buildx-context
        run: |
          docker context create builders

      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@b5ca514318bd6ebac0fb2aedd5d36ec1b5c232a2 # v3.10.0
        with:
          endpoint: builders
          platforms: ${{ matrix.platform }}

      - name: Login to GitHub Container Registry
        # This step logs in to the GitHub Container Registry (GHCR) using the docker/login-action.
        # It uses the GitHub actor's username and the GITHUB_TOKEN secret for authentication.
        uses: docker/login-action@74a5d142397b4f367a81961eba4e8cd7edddf772 # v3.4.0
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
#(...)

Set up Docker Context for Buildx: Creates a new context named "builders" for Buildx, allowing it to use the Docker daemon for building images.
Set up Docker Buildx: Configures Buildx (docker/setup-buildx-action@v3.10.0) with the specified context and platforms.
Login to GitHub Container Registry: Logs in to GHCR using docker/login-action@v3.4.0 with the GitHub actor's username and the GITHUB_TOKEN secret.

# (...)

      - name: Build and push by digest
        id: build
        uses: docker/build-push-action@471d1dc4e07e5cdedd4c2171150001c434f0b7a4 # v6.15.0
        env:
          DOCKER_BUILDKIT: 1
        with:
          context: .
          platforms: ${{ matrix.platform }}
          labels: ${{ steps.meta.outputs.labels }}
          annotations: ${{ steps.meta.outputs.annotations }}
          outputs: type=image,name=${{ env.GHCR_IMAGE }},push-by-digest=true,name-canonical=true,push=true,oci-mediatypes=true
          cache-from: type=gha,scope=${{ github.repository }}-${{ github.ref_name }}-${{ matrix.platform }}
          cache-to: type=gha,scope=${{ github.repository }}-${{ github.ref_name }}-${{ matrix.platform }}
#(...)

Build and push by digest: This is where the magic happens. It uses docker/build-push-action@v6.15.0 to build the image with the specified context and platforms. The image is built with the labels and annotations generated earlier.
outputs: Configures the action to push the image by digest, enabling better caching and versioning.
cache-from and cache-to: Enable caching for the build process, storing the cache in GitHub Actions cache and scoping it to the repository, branch, and platform.

# (...)

      - name: Export digest
        run: |
          mkdir -p /tmp/digests
          digest="${{ steps.build.outputs.digest }}"
          touch "/tmp/digests/${digest#sha256:}"

      - name: Upload digest      
        uses: actions/upload-artifact@4cec3d8aa04e39d1a68397de0c4cd6fb9dce8ec1 # v4.6.1
        with:
          name: digests-${{ env.PLATFORM_PAIR }}
          path: /tmp/digests/*
          if-no-files-found: error
          retention-days: 1
#(...)

Export digest: Creates a directory /tmp/digests and saves the digest of the built image to a file. The digest uniquely identifies the built image.
Upload digest: Uploads the digest file to GitHub Actions artifact storage using actions/upload-artifact@v4.6.1. The artifact is named digests-${{ env.PLATFORM_PAIR }} and is retained for 1 day.

# (...)
  merge:
    name: Merge Docker manifests
    runs-on: ubuntu-latest
    permissions:
      attestations: write
      actions: read
      checks: read
      contents: read
      deployments: none
      id-token: write
      issues: read
      discussions: read
      packages: write
      pages: none
      pull-requests: read
      repository-projects: read
      security-events: read
      statuses: read

    needs:
      - build
    steps:
      - name: Download digests
        uses: actions/download-artifact@cc203385981b70ca67e1cc392babf9cc229d5806 # v4.1.9
        with:
          path: /tmp/digests
          pattern: digests-*
          merge-multiple: true

merge: This job merges the Docker manifests for the different platforms built in the previous job.
needs: - build: Ensures that the build job completes successfully before starting.
Download digests: Downloads the digest files uploaded in the build job using actions/download-artifact@v4.1.9. The files are merged into the /tmp/digests directory.

      - name: Docker meta
        id: meta
        uses: docker/metadata-action@902fa8ec7d6ecbf8d84d538b9b233a880e428804 # v5.7.0
        with:
          images: ${{ env.GHCR_IMAGE }}
          annotations: |
            type=org.opencontainers.image.description,value=${{ github.event.repository.description || 'No description provided' }}
          tags: |
            type=raw,value=main,enable=${{ github.ref_name == 'main' }}
            type=raw,value=latest,enable=${{ github.ref_name == 'main' }}

      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@b5ca514318bd6ebac0fb2aedd5d36ec1b5c232a2 # v3.10.0
        with:
          driver-opts: |
            network=host

      - name: Login to GitHub Container Registry
        uses: docker/login-action@74a5d142397b4f367a81961eba4e8cd7edddf772 # v3.4.0
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - name: Get execution timestamp with RFC3339 format
        id: timestamp
        run: |
          echo "timestamp=$(date -u +"%Y-%m-%dT%H:%M:%SZ")" >> $GITHUB_OUTPUT

Docker meta: Generates metadata for the Docker image using docker/metadata-action@v5.7.0.
Set up Docker Buildx: Sets up Buildx again (docker/setup-buildx-action@v3.10.0).
Login to GitHub Container Registry: Logs in to GHCR (docker/login-action@v3.4.0).
Get execution timestamp with RFC3339 format: Gets the current UTC time in RFC3339 format for annotating the Docker manifest list.

      - name: Create manifest list and pushs
        working-directory: /tmp/digests
        id: manifest-annotate
        continue-on-error: true
        run: |
              docker buildx imagetools create \
                $(jq -cr '.tags | map("-t " + .) | join(" ")' <<< "$DOCKER_METADATA_OUTPUT_JSON") \
                --annotation='index:org.opencontainers.image.description=${{ github.event.repository.description }}' \
                --annotation='index:org.opencontainers.image.created=${{ steps.timestamp.outputs.timestamp }}' \
                --annotation='index:org.opencontainers.image.url=${{ github.event.repository.url }}' \
                --annotation='index:org.opencontainers.image.source=${{ github.event.repository.url }}' \
                $(printf '${{ env.GHCR_IMAGE }}@sha256:%s ' *)

      - name: Create manifest list and push without annotations
        if: steps.manifest-annotate.outcome == 'failure'
        working-directory: /tmp/digests
        run: |
              docker buildx imagetools create $(jq -cr '.tags | map("-t " + .) | join(" ")' <<< "$DOCKER_METADATA_OUTPUT_JSON") \
                $(printf '${{ env.GHCR_IMAGE }}@sha256:%s ' *)

      - name: Inspect image
        id: inspect
        run: |
          docker buildx imagetools inspect '${{ env.GHCR_IMAGE }}:${{ steps.meta.outputs.version }}'

Create manifest list and push: Creates a manifest list for the Docker images built for different platforms using docker buildx imagetools create. The manifest list is annotated with metadata and pushed to GHCR.
Create manifest list and push without annotations: If the previous step fails, this step creates the manifest list without annotations and pushes it to GHCR.
Inspect image: Inspects the created manifest list using docker buildx imagetools inspect to verify its contents.

There you have it! A complete, step-by-step guide to building multi-arch Docker images like a pro, using native GitHub Runners and leaving QEMU in the dust. Now go forth and conquer the world of multi-architecture deployments!

[

GitHub - sredevopsorg/multi-arch-docker-github-workflow: How to build a Multi-Architecture Docker Image in Github Actions using multiple runners without QEMU

How to build a Multi-Architecture Docker Image in Github Actions using multiple runners without QEMU - sredevopsorg/multi-arch-docker-github-workflow

GitHubsredevopsorg

](https://github.com/sredevopsorg/multi-arch-docker-github-workflow?ref=sredevops.org)

WebAssembly listo para producción? WASI Preview 2 lo hace realidad

Nicolás A. Georger — Wed, 10 Apr 2024 19:56:47 +0000

Resumen:

WebAssembly, o Wasm para abreviar, ha prometido desde hace mucho tiempo revolucionar el desarrollo de aplicaciones. El sueño era simple pero poderoso (y familiar): escribe tu código una vez y hazlo funcionar en cualquier lugar. Wasm también prometió ejecutar código a velocidades cercanas a las nativas. Incluso mejor, a diferencia de intentos anteriores de runtimes universales como Java, Wasm ofreció garantías de seguridad más elevadas y una postura de seguridad predeterminada deny-by-default (el acceso a los recursos del sistema está deshabilitado a menos que un desarrollador lo indique de otra manera).

Hasta hace poco, la realidad de Wasm no alcanzó el potencial prometido. Las herramientas y características críticas necesarias para una adopción más amplia todavía faltaban. Sin embargo, WASI Preview 2 ha llenado esas brechas y ha abierto la puerta a la adopción masiva de Wasm en entornos de producción.

El modelo de componentes y el soporte HTTP integrado en WASI Preview 2 simplifican ciertos aspectos en comparación con POSIX, haciendo que WASI sea una interfaz más moderna y portable para aplicaciones web y back-end. Con esta tecnología, los desarrolladores pueden elegir bibliotecas de cualquier ecosistema o lenguaje, compilarlas como módulos y estructurarlos en una sola aplicación. Esto permite que los equipos dentro de una organización desarrollen sistemas con el stack de su preferencia y luego unifiquen sus componentes y módulos en una aplicación monolítica.

No es difícil ver cómo WASI Preview 2 ha transformado la posibilidad del futuro de Wasm. Esta tecnología debe impulsar un aumento rápido en la adopción y despliegue de Wasm, lo que beneficiará a desarrolladores e inversionistas tecnológicos alrededor del mundo. WASI Preview 2 es el punto de inflexión que lleva a una era de desarrollo de software más fácil, rápido y seguro para todos.

¿Por qué WASI Preview 2 hace que WebAssembly esté listo para producción?

WebAssembly, o Wasm para abreviar, ha prometido desde hace mucho tiempo revolucionar el desarrollo de aplicaciones. El sueño era simple pero poderoso (y familiar): escribe tu código una vez y hazlo funcionar en cualquier lugar. Wasm también prometió ejecutar código a velocidades cercanas a las nativas. Incluso mejor, a diferencia de intentos anteriores de runtimes universales como Java, Wasm ofreció garantías de seguridad más elevadas y una postura de seguridad predeterminada deny-by-default (el acceso a los recursos del sistema está deshabilitado a menos que un desarrollador lo indique de otra manera).

Hasta hace poco, la realidad de Wasm no cumplía con la promesa. A pesar del enorme potencial y la comunidad creciente, Wasm carecía de las herramientas, interfaces y APIs necesarias para que fuera verdaderamente apto para producción. Los desarrolladores que deseaban usar Wasm tenían que convertirse en expertos en Wasm, adentrándose en aguas oscuras y sin documentar o recurrir a empresas especializadas en Wasm como Cosmonic o Fermyon, que ofrecen PaaS simplificadoras de la curva inicial de aprendizaje.

Más que una vista previa: estabilizando el modelo de componente

WASI Preview 2, aunque se llame "vista previa", es sólo el nombre. WASI Preview 2 es el eslabón perdido que Wasm necesitaba para volverse una opción viable para casos de uso en producción. WASI, que significa "Interfaz de Sistema WebAssembly" (Inglés), es un conjunto de estándares que definen una manera estándar y segura para que los módulos Wasm interactúen con recursos de sistema. WASI Preview 2 representa un hito significativo en la evolución de Wasm porque provee un standard sólido desde el cual los desarrolladores pueden construir con confianza sabiendo que toda la plataforma no va a tener cambios que impliquen refactoring o incompatibilidades (similar a API versioning).

En el corazón de WASI Preview 2 se encuentra el Modelo de Componente WebAssembly. Esta pieza crucial del rompecabezas brinda una manera de componer módulos Wasm en componentes más grandes, incluso si fueron programados en diferentes lenguajes. Es un gran paso adelante en términos de flexibilidad y compatibilidad. El modelo de componentes define una IAB canónica (interfaz de aplicación binaria) que estandariza la manera en que los componentes se comunican entre sí y les impide acceder a las memorias de otros componentes. Esto elimina los tipos de errores y vulnerabilidades de seguridad más comunes.

Otro aspecto clave de WASI Preview 2 es la estabilización de las API. Esto garantiza la compatibilidad en el futuro para aplicaciones Wasm, dando a los desarrolladores la confianza para construir encima de Preview 2 sin preocuparse por desastres futuros. Es análogo al modo en que POSIX (la Interfaz de Sistema Portátil) estandarizó las interfaces a través de sistemas operativos Unix, facilitando en gran medida la creación de software "portable".

Más allá de 'POSIX para Wasm'

Pero WASI tiene la intención de ir más allá, incluidas las interfaces para todas las cosas que no son necesariamente recursos de sistema. WASI incluye HTTP como una interfaz de primera clase, una capacidad de red y conexión crítica que no está presente en POSIX, brindando mejores opciones para mantener tracing de lo que un módulo está permitido hacer en lugar de manejarlo como un socket (por supuesto, también puedes hacer eso). También simplifica ciertos aspectos en comparación con POSIX que hacen que WASI Preview 2 sea una interfaz más moderna y portable — tanto para aplicaciones web como de back-end.

Las implicaciones prácticas de WASI Preview 2 son enormes. Anteriormente, los desarrolladores lucharon por construir aplicaciones Wasm fuera de sistemas especializados (como PaaS que enmascaraban la complejidad). La falta de APIs y herramientas estables hizo difícil la confianza en Wasm como tecnología apta para producción. Preview 2 cambia todo eso, allanando el camino para una adopción más amplia, incluso mayoritaria, de Wasm.

En resumen, cuando se construyen aplicaciones Wasm, ahora se pueden elegir bibliotecas (o mal llamadas librerías) de cualquier ecosistema o lenguaje, compilarlas como módulos y estructurarlos para hacer una sola aplicación. Los equipos dentro de su organización pueden desarrollar los sistemas de los que son responsables con el stack que prefieran. Luego, a través de componentes y módulos, los desarrolladores y equipos pueden unificarlos en una aplicación monolítica con la confianza de que las piezas encajarán y se comportarán de manera predecible.

No hay duda de que Wasm siempre ha sido una tecnología con un enorme potencial. Hasta ahora, ese potencial ha sido frenado por brechas en las herramientas, la estabilidad y las características críticas. WASI Preview 2 llena esas brechas agradablemente, allanando el camino para que Wasm realice su promesa de amigabilidad con el desarrollador en entornos de producción. WASI Preview 2 y el modelo de componentes deben impulsar un aumento rápido en la adopción y el despliegue de Wasm. Por encima de todo, es un gran paso adelante que debería entusiasmar a cualquier desarrollador o líder tecnológico sobre el futuro de Wasm y alentarlos a ensuciarse las manos construyendo aplicaciones Wasm.

Cada gran cambio tecnológico tiene un punto de inflexión que impulsa la adopción. WASI Preview 2 debería ser ese punto de inflexión para Wasm. Hará que desarrollar software sea más fácil, más rápido y más seguro para los desarrolladores en todas partes.

Adaptación del original por Oscar Spencer en The New Stack:

](https://thenewstack.io/why-wasi-preview-2-makes-webassembly-production-ready/?ref=sredevops.org)