Una comparativa publicada por Naranjatec presenta su Cloud Privado como una alternativa más económica a Stackscale utilizando como referencia el coste de CPU, memoria RAM y almacenamiento. El planteamiento permite hacerse una idea del precio de determinados recursos, pero no basta para determinar qué plataforma resulta realmente más económica cuando las arquitecturas, el modelo de cómputo, el almacenamiento, la alta disponibilidad y los servicios asociados no son necesariamente equivalentes. Además, en un mercado condicionado por el coste del hardware y especialmente de componentes como la memoria, convertir precios puntuales en conclusiones permanentes puede hacer que cualquier comparación envejezca rápidamente.

Las claves de la comparativa Stackscale-Naranjatec en 30 segundos

• Naranjatec compara recursos virtuales con una infraestructura que Stackscale comercializa principalmente sobre nodos físicos dedicados.
• Un vCore o vCPU no equivale necesariamente a un núcleo físico, por lo que comparar sus precios unitarios puede inducir a conclusiones equivocadas.
• El almacenamiento NVMe local y el almacenamiento empresarial centralizado en red resuelven necesidades diferentes.
• Alta disponibilidad, snapshots, replicación, Disaster Recovery, networking y soporte también forman parte del coste.
• Para saber qué proveedor es realmente más económico habría que pedir a ambos exactamente la misma arquitectura y comparar su coste total.

La cuestión no consiste en determinar si los precios publicados por un proveedor son mejores o peores. Naranjatec puede ofrecer una propuesta económicamente atractiva para determinados proyectos. El problema aparece cuando el precio de una unidad se utiliza para inferir el coste de una infraestructura completa.

La documentación utilizada como punto de partida para este análisis plantea precisamente esa diferencia: una comparación rigurosa debería normalizar arquitectura, almacenamiento, disponibilidad, networking, soporte y condiciones contractuales antes de determinar cuál es la alternativa económicamente más favorable.

En infraestructura empresarial dos ofertas con la misma cantidad nominal de CPU, RAM y terabytes pueden estar proporcionando servicios muy diferentes.

Una vCPU y un núcleo físico no son la misma unidad

El primer aspecto que debería revisarse en cualquier comparación de este tipo es la CPU.

Naranjatec expresa parte de su oferta mediante vCores. Stackscale estructura su Cloud Privado alrededor de nodos físicos dedicados que incorporan un número determinado de procesadores, cores, memoria y almacenamiento local. Actualmente ofrece generaciones basadas tanto en Intel Xeon como en AMD EPYC.

Convertir posteriormente esos servidores en un precio teórico por core para enfrentarlo al precio de una vCPU introduce una simplificación importante.

Un core físico es un recurso del procesador instalado en el servidor.

Una vCPU o vCore es una abstracción presentada por el hipervisor a una máquina virtual. La capacidad efectiva que representa depende del procesador físico, su generación y frecuencia, la política de planificación del hipervisor, el número de cargas simultáneas y la política de asignación de recursos.

Esto no significa que una vCPU tenga necesariamente peor rendimiento.

Significa que no puede establecerse una equivalencia universal del tipo una vCPU = un core físico.

Dos plataformas pueden anunciar 100, 200 o 500 vCPU y proporcionar capacidades reales diferentes. Para compararlas correctamente habría que conocer qué procesadores hay debajo, cuántos recursos físicos están disponibles y qué política de asignación aplica cada plataforma.

Por la misma razón, sumar de forma independiente CPU y RAM para estimar el precio de Stackscale tampoco refleja necesariamente su modelo comercial.

Stackscale comercializa Cloud Privado sobre servidores dedicados donde CPU y memoria forman parte del mismo nodo.

El cliente no está comprando necesariamente una bolsa abstracta de vCPU y gigabytes de memoria, sino capacidad física que posteriormente puede virtualizar mediante Proxmox VE o VMware.

El almacenamiento es donde más se complica la comparación

La capacidad es probablemente la métrica más engañosa cuando se comparan sistemas de almacenamiento.

Dos infraestructuras pueden ofrecer 10 TB y estar resolviendo problemas completamente diferentes.

Un servidor con discos NVMe locales puede proporcionar latencias muy reducidas y un elevado número de operaciones de entrada/salida por segundo (IOPS). Para bases de datos, cachés, procesamiento intensivo y muchas otras cargas puede ser una excelente elección.

También suele ser una forma eficiente de obtener mucho rendimiento por euro invertido.

El problema aparece cuando se compara directamente con almacenamiento empresarial centralizado como si únicamente cambiase el precio del gigabyte.

Stackscale combina discos locales en sus nodos con una plataforma independiente de almacenamiento centralizado en red, con distintos niveles de servicio. Su documentación pública especifica almacenamiento basado en sistemas NetApp, diferentes objetivos de latencia e IOPS, snapshots y georreplicación para varios de sus niveles.

Además dispone de almacenamiento con replicación síncrona entre dos centros de datos de Madrid orientado a arquitecturas que requieren objetivos de punto y tiempo de recuperación RPO y RTO igual a cero bajo las condiciones del servicio.

Por tanto, hablar simplemente de “almacenamiento” oculta una parte importante de lo que se está comparando.

Característica	NVMe local	Almacenamiento empresarial en red
Ubicación	Dentro del servidor	Plataforma de almacenamiento independiente
Latencia	Potencialmente muy baja	Depende del tier y de la red
IOPS	Generalmente elevados	Dependen del servicio contratado
Dependencia del nodo	Alta si no existe otra capa de protección	Cómputo y datos pueden estar desacoplados
Acceso desde varios nodos	Requiere arquitectura adicional	Puede diseñarse como almacenamiento compartido
Movilidad de VMs	Depende de replicación o migración de discos	Más sencilla con almacenamiento compartido
Snapshots	Dependen de la solución	Pueden formar parte de la plataforma
Replicación geográfica	Requiere mecanismos adicionales	Puede estar integrada en el servicio
Uso típico	Rendimiento local y cargas específicas	Virtualización, HA, continuidad y datos persistentes

Ninguna de las dos aproximaciones es universalmente mejor.

Lo importante es saber qué necesita realmente la aplicación.

Si una empresa busca capacidad NVMe rápida dentro de un servidor y dispone de su propia estrategia de protección de datos, el almacenamiento local puede ofrecer una relación coste/rendimiento excelente.

Si necesita mover máquinas entre hosts, desacoplar cómputo y datos, mantener snapshots o replicar información entre ubicaciones, el problema es diferente.

Y también lo será su coste.

¿Qué ocurre cuando falla un nodo?

Este escenario permite apreciar mejor la diferencia.

Una máquina virtual puede encontrarse en un servidor y almacenar sus discos únicamente en los NVMe locales de ese mismo equipo.

Si el servidor sufre un fallo físico, recuperar la máquina en otro nodo dependerá de los mecanismos adicionales que se hayan desplegado: replicación, almacenamiento distribuido, backup u otra tecnología.

En un clúster que utiliza almacenamiento compartido accesible desde diferentes servidores, otro nodo puede continuar accediendo a los datos. Con una plataforma de alta disponibilidad correctamente diseñada, la máquina virtual puede arrancarse en otro host.

No debe deducirse de esto que Naranjatec carezca de mecanismos para afrontar un fallo de servidor. La ausencia de detalle público sobre una característica concreta no demuestra que esa funcionalidad no exista.

La pregunta adecuada para cualquier proveedor sería:

¿Qué ocurre con mis máquinas y mis datos cuando falla completamente uno de los servidores?

Y después: ¿qué RPO, RTO y SLA están comprometidos?

Estas respuestas dicen mucho más sobre una plataforma que el precio de 1 GB.

KVM y Proxmox tampoco son conceptos opuestos

Existe otra comparación que merece una aclaración técnica.

Naranjatec indica que utiliza KVM junto con Virtualizor. Stackscale ofrece Proxmox VE como una de sus principales plataformas de virtualización.

Pero Proxmox VE también utiliza KVM para ejecutar máquinas virtuales.

La diferencia está en las capas de gestión y en cómo se construye posteriormente la infraestructura.

Proxmox VE integra virtualización KVM y contenedores LXC junto con gestión de clúster, alta disponibilidad, almacenamiento, networking, migración y administración centralizada. Puede complementarse además con Proxmox Backup Server para construir una plataforma de protección específica.

Stackscale ofrece Proxmox sobre sus nodos dedicados y lo combina, dependiendo del diseño contratado, con almacenamiento empresarial y redes privadas de alta capacidad.

Virtualizor cumple también la función de gestionar entornos virtualizados y no sería correcto concluir únicamente por el nombre de la plataforma que una alternativa es superior.

De nuevo, lo que debe compararse es la arquitectura resultante.

¿Cuántos nodos existen? ¿Hay clúster? ¿Cómo se gestiona el quorum? ¿Dónde residen los discos de las máquinas? ¿Existe HA? ¿Qué sucede si se pierde un host? ¿Cómo se realizan los backups?

Responder a esas preguntas permite comparar plataformas.

Comparar únicamente el hipervisor, no.

Alta disponibilidad: la capacidad que se paga pero se espera no utilizar

Existe además un coste especialmente difícil de representar en una tabla por vCPU: la capacidad de reserva.

Supongamos que una empresa necesita tres servidores para soportar toda su carga.

Puede contratar tres equipos y utilizarlos prácticamente al máximo.

Pero si necesita que las aplicaciones continúen funcionando cuando uno falle, la arquitectura tendrá que disponer de capacidad suficiente en los restantes para asumir las máquinas afectadas.

Ese margen tiene un coste aunque durante la mayor parte del tiempo no se utilice.

Stackscale documenta arquitecturas de Cloud Privado con nodos dedicados, redundancia y capacidades de alta disponibilidad. Su plataforma contempla además nodos de reserva y opciones de replicación geográfica.

La cuestión es aplicable a cualquier proveedor.

Tener tres servidores no equivale automáticamente a tener alta disponibilidad.

También se necesitan almacenamiento, red, quorum, capacidad libre, mecanismos de detección de fallos y procedimientos para recuperar las cargas.

Por eso una VM que utiliza ocho vCPU puede tener un coste muy diferente dependiendo de lo que se espera que ocurra cuando su servidor físico desaparece.

La red también forma parte de la infraestructura

El networking suele quedar relegado a una línea secundaria en muchas comparativas cloud.

En una plataforma distribuida es una pieza central.

Stackscale documenta nodos con enlaces de alta capacidad y diferentes generaciones con conexiones que alcanzan varias decenas de gigabits por segundo, además de una infraestructura redundante para almacenamiento, interconexión privada y salida a Internet.

Eso no significa que una interfaz con una cifra mayor haga automáticamente mejor a un proveedor.

Una aplicación web sencilla probablemente nunca se acerque a esos límites.

Pero la situación cambia cuando por la red circulan accesos al almacenamiento, migraciones de máquinas virtuales, replicación, backups o grandes volúmenes de tráfico entre nodos.

En esas arquitecturas la red interna puede determinar el rendimiento del conjunto.

La comparación correcta debería incluir por tanto capacidad, redundancia, topología, tráfico incluido y conectividad entre los diferentes elementos de la plataforma.

Una ubicación y varias ubicaciones resuelven problemas diferentes

Algo parecido ocurre con los centros de datos.

Una infraestructura alojada en un único centro de datos puede ser perfectamente válida para muchas aplicaciones.

Cuando aparecen requisitos de Disaster Recovery, replicación geográfica o continuidad ante la pérdida completa de una ubicación, disponer de infraestructura en otros centros permite construir diseños diferentes.

Stackscale publica Cloud Privado en Madrid y Ámsterdam y dispone de soluciones de replicación y recuperación ante desastres apoyadas en su infraestructura de almacenamiento y red. Su servicio de almacenamiento síncrono utiliza dos centros de datos de Madrid separados físicamente.

Naranjatec publica su infraestructura cloud en Ámsterdam.

Esto no convierte automáticamente una plataforma en mejor que otra.

Una empresa que únicamente necesite alojar una aplicación en Países Bajos puede no obtener ningún beneficio de disponer de más ubicaciones.

Para otra que necesite separar producción y Disaster Recovery entre centros de datos, esa posibilidad sí puede tener valor económico y operativo.

Snapshot, backup, réplica y Disaster Recovery no son sinónimos

Otro error frecuente en comparativas de infraestructura consiste en agrupar todas las tecnologías de protección bajo la palabra “backup”.

Un snapshot permite recuperar un estado anterior del almacenamiento.

Un backup crea una copia destinada a recuperación con unas determinadas políticas de retención.

Una réplica mantiene otra copia de los datos en un sistema diferente.

La replicación síncrona busca que los sistemas mantengan la información actualizada simultáneamente.

Y Disaster Recovery define cómo recuperar aplicaciones y servicios completos ante una contingencia.

Stackscale documenta snapshots y georreplicación dentro de varios niveles de su almacenamiento en red, además de servicios específicos de backup y DR.

Esto es relevante porque una misma capacidad de 10 TB puede incorporar niveles de protección completamente diferentes.

Preguntar únicamente cuánto cuesta almacenar esos 10 TB deja fuera precisamente el coste de protegerlos.

Qué debería incluir una comparación realmente equivalente

La tabla original puede ser útil como aproximación comercial, pero resulta insuficiente para decidir qué infraestructura ofrece menor coste para ejecutar las mismas aplicaciones.

Una comparación más completa tendría un aspecto parecido a este:

Aspecto	Qué debería normalizarse
CPU	Modelo, generación, cores físicos, threads y asignación de vCPU
RAM	Capacidad física y capacidad realmente disponible
Virtualización	Hipervisor, gestión, clustering y licencias
Nodos	Número de servidores y capacidad de cada uno
Redundancia	N, N+1 u otra arquitectura
Almacenamiento	Local, compartido o distribuido
Rendimiento storage	IOPS, throughput y latencia
HA	Comportamiento ante el fallo completo de un nodo
Snapshots	Frecuencia y retención
Backup	Tecnología, capacidad, retención y ubicación
Replicación	Síncrona o asíncrona y distancia entre copias
DR	Procedimiento y ubicación alternativa
RPO/RTO	Pérdida máxima de datos y tiempo de recuperación
Networking	Interfaces, redundancia y capacidad interna
Internet	Ancho de banda y tráfico incluido
SLA	Qué componentes cubre y con qué disponibilidad
Soporte	Horario, alcance y responsabilidades
Contrato	Permanencia, alta y compromisos mínimos
Escalabilidad	Coste y procedimiento para crecer

Entonces sí tendría sentido solicitar dos presupuestos.

Por ejemplo, una empresa podría pedir una plataforma con una determinada capacidad utilizable de CPU y 1 TiB de RAM, 10 TiB de almacenamiento, tolerancia al fallo de un nodo, almacenamiento compartido, determinados niveles de IOPS y latencia, snapshots, backup con una retención concreta, replicación geográfica, un RPO y RTO definidos, conectividad redundante y soporte 24/7.

Ambos proveedores tendrían que responder al mismo problema.

El precio final de esas dos propuestas sería una comparación mucho más útil que dividir el coste de una vCPU entre el de otra.

Naranjatec puede ser más barato y la comparación seguir siendo insuficiente

Existe una distinción importante.

Cuestionar la metodología utilizada para comparar ambas plataformas no implica afirmar que Naranjatec sea necesariamente más caro.

Puede ocurrir justamente lo contrario.

Para una empresa que priorice precio, necesite hardware dedicado con virtualización y almacenamiento local de alto rendimiento y no requiera determinados niveles de almacenamiento centralizado, replicación, HA o Disaster Recovery, su propuesta puede resultar económicamente muy competitiva.

El error sería extrapolar automáticamente ese resultado a cualquier proyecto.

Stackscale plantea un modelo de infraestructura empresarial basado en nodos físicos dedicados que pueden combinarse con Proxmox VE, almacenamiento centralizado, distintos niveles de servicio, redes de alta capacidad, alta disponibilidad, replicación y diferentes ubicaciones.

Todo eso cuesta dinero.

Pero eliminarlo de la comparación no hace que desaparezca su coste: hace que se estén comparando servicios diferentes.

Este matiz adquiere todavía más importancia en un momento en el que los costes del hardware pueden experimentar cambios relevantes. Memoria, almacenamiento, procesadores y otros componentes afectan directamente al coste de construir infraestructura dedicada, por lo que una fotografía de precios tomada en un momento determinado puede quedar desactualizada.

Para un CIO o responsable de infraestructura, la pregunta útil no debería ser quién vende más barato una vCPU.

Debería ser cuánto cuesta mantener sus aplicaciones funcionando con el rendimiento, disponibilidad, protección de datos y capacidad de recuperación que realmente necesita la empresa.

Y para responder a eso hay que mirar bastante más abajo de la máquina virtual.

Más barato por vCPU no significa necesariamente más barato para ejecutar la misma infraestructura.

Preguntas frecuentes

¿Se puede comparar directamente el precio por vCPU de dos proveedores cloud?

Solo cuando las condiciones subyacentes son suficientemente equivalentes. Procesadores, asignación de recursos, overcommit, arquitectura física y nivel de servicio pueden hacer que dos vCPU representen capacidades diferentes.

¿Es mejor el almacenamiento NVMe local o el almacenamiento en red?

Depende de la aplicación. NVMe local puede proporcionar una excelente relación entre rendimiento y coste, mientras que el almacenamiento centralizado resulta especialmente útil cuando se necesitan datos independientes del nodo, almacenamiento compartido, HA, snapshots o replicación.

¿Proxmox VE utiliza KVM?

Sí. Proxmox VE utiliza KVM para virtualizar máquinas y añade una plataforma de administración que incorpora clustering, HA, networking, almacenamiento y otras funciones.

¿Cómo debería compararse el precio de dos clouds privados?

Solicitando una arquitectura equivalente a ambos proveedores y definiendo CPU, RAM, almacenamiento, redundancia, HA, backup, replicación, networking, SLA, RPO, RTO, soporte y duración contractual antes de comparar el coste total.

Fuentes:

• Naranjatec, comparativa Alternativa más económica a Stackscale y documentación pública de Cloud Privado.
• Stackscale, documentación de Cloud Privado y nodos dedicados.
• Stackscale, documentación de almacenamiento en red y georreplicación síncrona.
• Stackscale, soluciones de Disaster Recovery y backup.
• Proxmox, documentación oficial de Proxmox Virtual Environment.

Aviso sobre precios y condiciones: Las características, tarifas y condiciones comerciales de los servicios cloud pueden cambiar, especialmente en periodos de variación de costes de componentes como memoria RAM, almacenamiento y procesadores. Este artículo analiza principalmente las diferencias arquitectónicas y de servicio y no debe interpretarse como una cotización comercial. Para realizar una comparación económica actualizada es recomendable solicitar propuestas a los proveedores sobre la misma arquitectura, capacidad, nivel de disponibilidad, soporte y condiciones contractuales.