Planes, crédito y consumo

Operaciones#

Planes y habilitaciones#

Un plan es free o premium. Las habilitaciones son capacidades que un operador de la plataforma activa manualmente para la organización:

El documento del plan lleva una version que aumenta con cada cambio de plan o de habilitaciones. Un operador de la plataforma la envía de vuelta como expected_version, de modo que un cambio concurrente se rechaza en lugar de sobrescribirse. Los miembros de la organización solo la leen.

La lista de espera#

Una organización solicita premium entrando en la lista de espera:

{ "interest": ["diagnostics", "private_apps"], "note": "Internal tools" }

interest acepta diagnostics, private_apps, premium_execution y workspace_development. Una organización tiene una sola entrada abierta; repetir la solicitud la actualiza. La entrada registra al miembro que la pidió, y su estado es waiting, invited, enabled o declined. La habilitación y el crédito siempre van a la organización, nunca al usuario.

Admisión interna de personas#

Mientras la política de admisión de la plataforma es closed, la gestión y la preparación están abiertas a las personas que Beyond admitió, una por una, y a nadie más. Iniciar sesión, crear una organización o tener un rol no admite a nadie: a un miembro cuyo rol permite una operación se le responde 403 ADMISSION_REQUIRED (details.policy nombra la política) hasta que un operador lo admite. Las lecturas de contenido público, session.read y las dos operaciones de abajo siguen abiertas a cualquier persona con sesión.

GET /v1/admission responde la situación del propio solicitante —none, waiting, enabled o revoked— y no revela nada de nadie más. PUT /v1/admission, con una note opcional, agrega la entrada person del solicitante a la misma lista de espera, o actualiza su nota; una persona tiene una sola entrada, repetir la solicitud deja el mismo estado, y volver a pedir nunca deshace la decisión de un operador, incluida una revocación. La admisión se decide en el backoffice de la plataforma: admite solo a esa persona, y no otorga rol, organización, plan, crédito ni capacidad de plataforma alguna. Una revocación rechaza la siguiente solicitud de gestión o preparación de la persona; el trabajo ya encolado o en ejecución se deja terminar, y el contenido publicado conserva su visibilidad. Bajo la política open nadie es rechazado solo por admisión.

Pedir el desarrollo en Workspace#

workspace_development le pide a Beyond que habilite el desarrollo cerrado en Workspace para la organización. Viaja por esta lista de espera y no es una habilitación de CDN:

• revisar o aprobar una entrada así no cambia ningún plan, ninguna habilitación ni ningún crédito;
• el acceso a Workspace se decide por separado, en Beyond Projects, para la organización y para cada miembro que Beyond selecciona. Entrar en la lista de espera no habilita nada por sí solo;
• la organización igual puede pedir premium con la misma entrada o con una posterior.

En la administración de CDN, el formulario de la lista de espera tiene la casilla Desarrollo en Workspace (acceso cerrado) bajo Qué le interesa a tu organización, con la explicación «Pide al equipo de Beyond habilitar el desarrollo en Workspace para esta organización y los miembros que seleccione. Se decide por separado y nunca cambia el plan ni el crédito de CDN.» Después de que se aprueba una solicitud así, la página dice «El equipo de Beyond aprobó esta solicitud sin cambiar el plan de CDN: el desarrollo en Workspace se habilita por separado, para la organización y para cada miembro seleccionado. Aún puedes pedir Premium aquí abajo.» Solo un propietario o administrador de la organización puede entrar en la lista de espera.

Esta parte es Experimental: está implementada y se ejecutó en una instalación local, y nada está alojado.

Crédito#

El crédito es crédito de prueba en la nube que un operador le otorga a la organización. Nunca es un saldo por usuario.

El libro de crédito solo admite agregados. Cada entrada tiene un kind (grant, reserve, settle, release), un amount y una key única, de modo que una liquidación o un otorgamiento reintentado se registra una sola vez.

amount es siempre positivo. El kind indica el sentido: grant y release aumentan lo disponible, reserve lo retiene y settle lo consume. Un release informa lo que volvió al saldo, nunca un cargo, y el libro no contiene cargos de cero. El trabajo se admite solo si el crédito disponible de la organización y el presupuesto global de la plataforma pueden cubrir la reserva; de lo contrario, la respuesta es 402 CREDIT_INSUFFICIENT o 503 BUDGET_EXHAUSTED.

Consumo#

usage.read acepta from, to, category, application, after y limit, y responde los totales por categoría y una página de registros. from es el inicio del período, inclusivo, y to es su fin, exclusivo, ambos como instantes UTC. Sin ellos, el período es el mes UTC en curso hasta ahora.

Un registro lleva ms, bytes, credits, cache_hit y el attempt que se midió. Cada total agrega hits.

El trabajo compartido se mide una sola vez#

Una unidad compartida compatible se ejecuta y se mide una vez, y se atribuye a su primer pagador autorizado. Todos los demás consumidores registran un acierto de caché con cero créditos. Un intento es único, así que nunca se registra dos veces, ni siquiera cuando el mismo trabajo llega dos veces a un worker.

La intención de los precios futuros es cobrar el procesamiento real, no la cantidad de módulos. Esa intención no es una tarifa.