Glosario

Ver también: Glosario Cloud Native

Si deseas referirte a estas definiciones fuera del alcance de los documentos del grupo de trabajo, ten en cuenta que han sido escritas en el contexto de la CNCF y el despliegue de aplicaciones.

Plataforma (Platform)

Colección de capacidades, documentación y herramientas que apoyan el desarrollo, despliegue, operativa y/o gestión de la entrega de productos y servicios. Una plataforma puede incluir portales web, APIs, CLIs, definiciones de protocolos, documentación, estándares y/o plantillas de “golden path”. Cuando se hace bien, las plataformas permiten un despliegue más rápido y fiable de las aplicaciones y servicios de una organización.

Dependiendo del alcance y la audiencia para una plataforma, a veces se puede referir a ella como una “Plataforma de Desarrollo”, una “Plataforma de Desarrollo Interno (IDP)”, una “Plataforma de Entrega”, una “Plataforma de Aplicaciones” o incluso una “Plataforma en la Nube”. El término “Plataforma como Servicio (PaaS)” también se usa a menudo para describir plataformas que se compran o adoptan desde fuera de una organización, proporcionando una solución de plataforma más gestionada pero a menudo menos personalizable.

Ingeniería de Plataforma (Platform engineering)

El diseño, construcción, operación y evolución de una plataforma. Una forma de verlo en la práctica es un enfoque impulsado por la empatía hacia el diseño organizacional sociotécnico¹. En este sentido, es un proceso continuo por el cual una organización aprende cómo y dónde invertir y hacer apuestas comerciales estratégicas internamente, en lugar de sólo externamente.

Equipo de Plataforma

Las personas responsables de construir y gestionar la(s) plataforma(s). Los miembros del equipo de plataforma incluyen ingenieros de plataforma, que se centran en la construcción de la herramienta y las capacidades que componen las experiencias de la plataforma. Puede incluir roles de gestor de producto de plataforma dedicados que se centran en satisfacer las necesidades de los clientes internos y al mismo tiempo apoyan los objetivos estratégicos más amplios de la organización. A medida que la plataforma evoluciona, otros roles especializados, como operadores, analistas de QA, diseñadores UI/UX, redactores técnicos y developer advocates, pueden ser añadidos a los equipos de plataforma.

DevOps

“DevOps es una metodología en la que los equipos son dueños de todo el proceso, desde el desarrollo de aplicaciones hasta las operaciones de producción."² Aunque las prácticas de DevOps pueden ser implementadas por equipos sin desarrollar una plataforma dedicada, puede ser útil ver la ingeniería de plataforma como un enfoque para escalar los principios de DevOps a través de la entrega y gestión de una plataforma unificada que sirva a toda la organización. Esta plataforma compartida tiene como objetivo racionalizar los procesos de desarrollo, despliegue y operativa, proporcionando un entorno estandarizado y eficiente para la entrega de software. Aunque DevOps y Platform Engineering convergen en los objetivos de optimizar la entrega de software y el rendimiento operativo, Platform Engineering se centra de manera distintiva en el desarrollo de un producto tangible: la plataforma en sí misma, para facilitar estos objetivos.

Usuarios de la Plataforma

Las personas que utilizan directamente las capacidades de la plataforma, incluyendo pero no limitado a desarrolladores de aplicaciones, operadores de aplicaciones, científicos de datos, operadores de software comercial off-the-shelf (COTS) y trabajadores de la información - quienes ejecutan software en la plataforma, utilizan capacidades proporcionadas por la plataforma o requieren información sobre el uso de la plataforma. Los usuarios de la plataforma pueden incluir a otros ingenieros de plataforma que crean servicios de plataforma de un nivel superior sobre capacidades de niveles inferiores.

Portal

Interfaz web que proporciona acceso centralizado a una variedad de recursos, herramientas y servicios. Puede servir como punto de partida para una amplia gama de usuarios con el fin de gestionar e interactuar eficientemente con las capacidades subyacentes de la plataforma. Un portal existe para mejorar la experiencia del usuario a través de una interfaz amigable que simplifica procesos complejos y promueve capacidades de autoservicio (self-service).

Capacidades de la Plataforma

El resultado específico para el usuario, o qué proporciona una plataforma. Estos no deben confundirse con las cualidades de la plataforma que describen cómo funcionan las capacidades. Estas capacidades pueden estar en diferentes niveles de abstracción (por ejemplo, una sola base de datos frente a un entorno de prueba que incluye una base de datos) y ser proporcionadas por diferentes proveedores de capacidades. A medida que las plataformas maduran, generalmente aspiran a ofrecer capacidades self-service, comenzando con la descubribilidad de las capacidades disponibles e incluyendo la consistencia de la experiencia a través de las capacidades. Las capacidades en sí mismas a menudo son bastante duraderas, mientras que los proveedores y la implementación pueden evolucionar más rápidamente. Por ejemplo, es poco probable que una organización deje de requerir entornos de prueba, pero pueden evolucionar para proporcionar soluciones contenerizadas en lugar de soluciones basadas en VM.

Proveedor de capacidades de la Platafora

Grupo de personas que desarrollan y mantienen una capacidad ofrecida por la plataforma. Los proveedores pueden ser organizaciones externas o equipos internos y en organizaciones más pequeñas a menudo pueden ser los mismos individuos que también desarrollan la plataforma más amplia. A medida que las plataformas maduran, se benefician de mantener abstracciones para los proveedores para desalentar el bloqueo y seguir avanzando hacia su Thinnest Viable Platform (plataforma más fina viable).

Calidades de la Plataforma

Se refiere a cómo la plataforma y sus capacidades funcionan y qué se puede esperar en términos de requisitos multifuncionales, requisitos no funcionales o simplemente “-idades”. Ejemplos incluyen la fiabilidad o el rendimiento de los servicios gestionados que pueden medirse con Service Level Objectives (SLOs), la seguridad que puede medirse con el tiempo de mitigación de los riesgos identificados, o la observabilidad que se puede utilizar tanto para depurar como para informar sobre el uso de la plataforma. A menudo se confunden las cualidades con las capacidades, ya que algunos conceptos, como la observabilidad, que se pueden ofrecer como una capacidad (por ejemplo, el Operador OTel proporcionado para recopilar la telemetría de la aplicación) y una calidad declarada (por ejemplo, métricas de la plataforma para medir y alertar sobre el tiempo de actividad de ese Operador OTel proporcionado).

Carga cognitiva

Una cuantificación de los costos mentales para un usuario antes de que puedan beneficiarse de una capacidad de la plataforma. Dentro del término general de carga cognitiva, en realidad hay tres tipos de carga: intrínseca, extraña y relacional. Las organizaciones son más saludables cuando las plataformas permiten a los usuarios centrarse en los desafíos de carga relacional (resolución de problemas específicos del trabajo) mientras simplifican la carga intrínseca (incorporación de nueva información o procesos para completar su tarea) y minimizan la carga extraña (distracciones de la tarea enfocada, a veces apodada “ yak shaving”).

Thinnest Viable Platform (TVP)

Concepto definido inicialmente en el libro Team Topologies de Matthew Skelton y Manuel Pais, que anima a las organizaciones a encontrar un equilibrio cuidadoso entre una plataforma pequeña pero efectiva. Al hacerlo, pueden acelerar y simplificar la entrega de software para los equipos que trabajan en la plataforma mientras alcanzan sus objetivos comerciales más amplios. Animan a las plataformas a centrarse en los requisitos únicos del negocio e integrar rutinariamente proveedores de capacidades de terceros que pueden reducir la complejidad y el coste operativo de la plataforma.