“¿Otra herramienta de observabilidad para Kubernetes? El mercado está saturado.” Lo escuchamos antes de escribir una sola línea de código, y es una crítica justa. Datadog, Grafana, New Relic y una docena más ya dominan ese terreno. Así que este post es la respuesta honesta a la pregunta obvia: ¿para qué construir KubeBolt?

La versión corta: la categoría no está saturada, está mal categorizada. Todos venden observabilidad. Casi nadie vende operación. Ese hueco es donde vive KubeBolt.

Tres incumbentes, tres puntos ciegos

Cada gran jugador es excelente en aquello para lo que fue construido, y ese origen es justo lo que lo limita para operar Kubernetes.

Datadog es generalista. Monitorea todo: VMs, serverless, bases de datos, APM, logs. Esa amplitud es su foso y su impuesto. Pagas por una plataforma que trata tu cluster como una fuente de datos más, no como aquello sobre lo que corre tu producto.
Grafana es una capa de visualización. Es brillante dibujando el gráfico, pero el gráfico es el final de su trabajo. Lo que pasa después de que la línea se pone roja sigue siendo cosa tuya.
New Relic y el resto del mundo APM son centrados en la aplicación. Te dicen que un request va lento; no te dicen que el PodDisruptionBudget está bloqueando tu drain.

Ninguno es un mal producto. Tienen la forma equivocada para la tarea de operar Kubernetes, y no pueden cambiar de forma sin reescribirse, porque su pricing, su modelo de datos y su UX asumen un mundo generalista de solo-observar.

El hueco: operar, no solo observar

Un dashboard que se pone en rojo te dice que existe un síntoma. No reúne contexto, no decide qué hacer, ni actúa. Toda persona de guardia conoce la brecha entre “algo va mal” y “ya está arreglado”, y esa brecha es donde se va la noche.

KubeBolt está construido para cerrarla. La misma superficie que te muestra un CrashLoopBackOff te deja arreglarlo: set image, escalar, rollback, drenar un nodo, bajo RBAC y con audit log en cada mutación. Encima va la resolución asistida (Kobi propone el fix, tú apruebas) y la remediación autónoma (Autopilot actúa dentro de guardarraíles y escribe el postmortem). La observabilidad es lo mínimo; lo que haces después de la alerta es el producto.

Pricing que escala con tu infra, no con tu headcount

Hay una segunda razón, más callada, por la que los incumbentes no pueden seguirnos aquí: cómo cobran.

La mayoría de las herramientas de observabilidad cobran por usuario activo o por host, además del volumen de datos. A medida que tu equipo crece, la factura crece con el headcount, no con la complejidad real de tu sistema. Eso es genial para el vendedor y al revés para ti: las personas que quieres metiendo mano en producción son justo las que el modelo de pricing castiga.

KubeBolt cobra por recurso. Tu factura sigue a la infraestructura que de verdad corres, e invitar a todo tu equipo no cuesta nada extra. Es una decisión pequeña con una consecuencia grande, y una que un incumbente per-seat no puede copiar sin romper su propio modelo de ingresos.

Por qué un equipo pequeño puede ganar esto

El instinto dice que no puedes superar a Datadog construyendo. No hace falta. Datadog tiene que hacer todo de forma aceptable. Nosotros hacemos una cosa, operaciones de Kubernetes, y podemos hacerla a fondo: tipos de recurso nativos, insights que entienden K8s, remediación que entiende controllers y rollouts. El foco es toda la ventaja. Un generalista no puede sobre-especializarse sin abandonar el generalismo que lo hacía valioso.

También ayuda que empezamos open source, Apache 2.0, y livianos: menos de 50 MB por nodo, sin Prometheus, sin bases de datos que operar. La forma más rápida de ganar confianza en infraestructura es dejar que la gente lea el código y lo corra ella misma.

Lo que KubeBolt no es

La honestidad incluye decir dónde no jugamos:

No es un APM. No vamos a trazar los spans internos de tu aplicación.
No es una plataforma de logs. No vamos a ser tu backend centralizado de logging.
No es monitoreo de VMs/serverless. Si no es Kubernetes, no somos nosotros.

Si necesitas eso, quédate con tus herramientas actuales: KubeBolt convive feliz al lado. Preferimos ser los mejores en una cosa que mediocres en diez.

Quién debería usar KubeBolt, y quién no

Probablemente deberías si corres workloads reales en Kubernetes, no tienes un ejército dedicado de SRE, y estás cansado de herramientas que diagnostican pero nunca actúan.

Probablemente no deberías (todavía) si tus necesidades de monitoreo son mayormente fuera de Kubernetes, o ya invertiste fuerte en un setup que opera, no solo observa, tu cluster.

Esa es toda la tesis. El mercado está lleno de herramientas que miran Kubernetes. Construimos la que lo opera. Si te resuena, el agente OSS se instala en menos de dos minutos: empieza por ahí.