Cloud Application Management for Platforms ( CAMP ) es una especificación para la gestión de aplicaciones en el contexto de un sistema de plataforma como servicio (PaaS). CAMP está diseñado para satisfacer las necesidades de un sistema PaaS de alto nivel, en el que el usuario (generalmente un desarrollador o administrador de aplicaciones) proporciona los componentes de la aplicación (código, datos, gráficos, etc.) y especifica los servicios del proveedor necesarios para implementarlos como una aplicación. El proveedor del sistema PaaS oculta al usuario los detalles de la infraestructura (computación, almacenamiento y redes) utilizada para dar soporte a estos servicios.
Descripción general

CAMP define lo siguiente:
- Un lenguaje específico de dominio que describe los artefactos que componen una aplicación, los servicios necesarios para ejecutar o utilizar dichos artefactos y la relación de los artefactos con esos servicios.
- Un modelo de recursos para representar las aplicaciones y sus componentes, así como los servicios utilizados por dichos componentes, junto con información sobre el estado de ejecución, información de configuración y metadatos que describen el sistema PaaS.
- Un protocolo REST para manipular estos recursos y, al hacerlo, cambiar el estado de la aplicación subyacente.
Historia
CAMPAMENTO 1.0
CAMP 1.0 [ 1 ] fue producido como una colaboración entre CloudBees, Cloudsoft Corporation, Huawei, Oracle, Rackspace, Red Hat y Software AG . [ 2 ] Fue publicado en agosto de 2012.
CAMPAMENTO 1.1
En agosto de 2012, CAMP 1.0 se presentó al Comité Técnico de CAMP de OASIS con la intención de elaborar un estándar de OASIS. Este Comité Técnico ha elaborado una Especificación del Comité de OASIS. [ 3 ] De acuerdo con sus estatutos, el Comité Técnico de CAMP está a la espera de evidencia de dos implementaciones interoperables de CAMP v1.1 antes de solicitar a OASIS que apruebe la especificación como un estándar de OASIS.
Motivación
La mayoría de los sistemas PaaS ofrecen algún tipo de API de gestión de aplicaciones . Estas API se utilizan para subir aplicaciones a la nube, configurar los servicios que se usarán para ejecutarlas, iniciarlas, supervisar su estado y rendimiento, detenerlas, etc. Estas API suelen estar ocultas tras una aplicación web o una herramienta de línea de comandos . Este tipo de API es una tecnología común; su existencia es un requisito previo necesario para que un sistema PaaS funcione correctamente, pero ofrecer una API de gestión superior a la de la competencia ofrece pocas ventajas. Nadie ha elegido jamás una oferta de PaaS basándose únicamente en la calidad de su API de gestión de aplicaciones.
Desventajas
El hecho de que cada sistema PaaS proporcione una API de gestión de aplicaciones personalizada genera una serie de problemas:
- Cualquier sistema de monitorización o gestión, sistema de integración continua , etc., diseñado para consumir dichas API, deberá reescribirse si un cliente desea cambiar o añadir sistemas PaaS adicionales. Esto incrementa el coste de cambiar de proveedor de PaaS, lo que, a su vez, disminuye el valor de utilizar PaaS.
- Los entornos de desarrollo integrados que deseen trabajar con plataformas PaaS deben hacerlo de forma individual, caso por caso (por ejemplo, proporcionando conectores personalizados para cada sistema PaaS). Esto aumenta tanto el esfuerzo de desarrollo inicial como la "deuda técnica" acumulada por el mantenimiento de cada uno de estos conectores.
- Dado que la calidad de la API de gestión de aplicaciones no es un factor diferenciador, invertir tiempo en diseñarla o ajustarla no es una buena inversión. Los proveedores de plataformas pueden ahorrar tiempo y recursos implementando una API básica y estandarizada. Las funcionalidades de valor añadido pueden implementarse como extensiones de esta API básica.
Implementaciones de CAMP
nCAMP
Desarrollado en colaboración con el Comité Técnico de OASIS CAMP, nCAMP es una implementación de prueba de concepto de la especificación CAMP v1.1. nCAMP no fue concebido como un sistema PaaS útil, sino como un vehículo para probar los conceptos y estructuras de la especificación CAMP. nCAMP presenta un sistema sencillo que utiliza Tomcat y MySQL para dar soporte a aplicaciones web basadas en Java Servlet que pueden usar MySQL como base de datos. [ 4 ]
Proyecto Solum
Solum es un proyecto de Stackforge relacionado con OpenStack , diseñado para facilitar el consumo e integración de servicios en la nube en el proceso de desarrollo de aplicaciones. El modelo de recursos y el esquema de planes de Solum se basan en CAMP, pero no cumplen completamente con este estándar. Actualmente se está trabajando para proporcionar una API adicional compatible con CAMP [ 5 ] , además de la API nativa de Solum.
Apache Brooklyn
Apache Brooklyn es un marco de trabajo para modelar, monitorear y administrar aplicaciones mediante planos autónomos. Los planos de Apache Brooklyn cumplen con el borrador de revisión pública 01 de CAMP v1.1.
Referencias
- ↑ Gestión de aplicaciones en la nube para plataformas, versión 1.0, agosto de 2012
- ↑ InfoQ, "CAMP 1.0 – Una API abierta para la gestión de aplicaciones PaaS", 31 de agosto de 2012.
- ↑ Gestión de aplicaciones en la nube para plataformas, versión 1.1, especificación del comité 01, 9 de noviembre de 2014. http://docs.oasis-open.org/camp/camp-spec/v1.1/cs01/camp-spec-v1.1-cs01.pdf
- ↑ "¿Cómo funciona la infraestructura en la nube?" . Consultado el 5 de junio de 2023 .
- ↑ Compatibilidad con la API de CAMP 1.1
Enlaces externos
- CAMPAMENTO en 7 diapositivas: Episodio 2
- Descripción general de la minería en la nube
- VPS en la nube IPv4
- Estándares de la nube