Cloud Application Management for Platforms ( CAMP ) es una especificación para gestionar aplicaciones en el contexto de un sistema de plataforma como servicio (PaaS). CAMP está diseñado para abordar las necesidades de un sistema PaaS de alto nivel; uno en el que el consumidor (generalmente un desarrollador o administrador de aplicaciones) proporciona artefactos de la aplicación (código, datos, gráficos, etc.) y especifica qué servicios proporcionados por el proveedor son necesarios para realizar estos artefactos como una aplicación. Los detalles de la infraestructura (computación, almacenamiento y redes) que se utilizan para respaldar estos servicios están ocultos al consumidor por el proveedor del sistema PaaS.
CAMP define lo siguiente:
- Un lenguaje específico de dominio que describe los artefactos que componen una aplicación, los servicios que se requieren para ejecutar o utilizar esos artefactos y la relación de los artefactos con esos servicios.
- Un modelo de recursos para representar aplicaciones y sus componentes constituyentes, así como los servicios utilizados por esos componentes junto con información de estado de tiempo de ejecución, información de configuración y metadatos que describen el sistema PaaS.
- Un protocolo RESTful para manipular estos recursos y, al hacerlo, cambiar el estado de la aplicación subyacente.
Motivación
La mayoría de los sistemas PaaS proporcionan alguna forma de API de administración de aplicaciones . Estas API se utilizan para cargar aplicaciones en la nube, configurar qué servicios se utilizarán para ejecutar la aplicación, iniciar la aplicación, supervisar el estado y el rendimiento de la aplicación, detener la aplicación, etc. Estas API suelen estar ocultas detrás de una aplicación web. y / o una herramienta de línea de comandos . Este tipo de API es una tecnología "yo también"; su existencia es un requisito previo necesario para proporcionar un sistema PaaS viable, pero hay pocas ventajas en proporcionar una API de gestión mejor que la de sus competidores. Nadie seleccionó una oferta de PaaS únicamente por la solidez de su API de administración de aplicaciones. Mientras tanto, el hecho de que cada sistema PaaS proporcione una API de administración de aplicaciones personalizada crea una serie de problemas:
- Cualquier sistema de supervisión o gestión, sistema de integración continua , etc. escrito para consumir dichas API deberá volver a redactarse si un cliente desea cambiar o agregar sistemas PaaS adicionales. Esto aumenta el costo de cambiar entre proveedores de PaaS lo que, a su vez, disminuye el valor de usar PaaS.
- Los entornos de desarrollo integrados que deseen apuntar a entornos 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 de mantener cada uno de estos conectores.
- Debido a que la calidad de la API de administración de aplicaciones no es un diferenciador, el tiempo dedicado a diseñar / ajustar la API de administración no es una buena inversión. Los proveedores de plataformas pueden ahorrar tiempo y recursos al implementar una API de consenso básica. Las funciones de valor agregado se pueden implementar como extensiones de esta API básica.
Historia
CAMP 1.0
CAMP 1.0 [1] se produjo 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 se presentó el CAMP 1.0 al Comité Técnico de OASIS CAMP con la intención de producir un Estándar OASIS. Este Comité Técnico ha elaborado una Especificación del Comité OASIS. [3] Según su estatuto, CAMP TC está esperando evidencia de dos implementaciones interoperables de CAMP v1.1 antes de pedirle a OASIS que apruebe la especificación como un Estándar OASIS.
Implementaciones CAMP
nCAMP
Desarrollado en conjunto con el trabajo del Comité Técnico de OASIS CAMP, nCAMP es una implementación de prueba de concepto de la especificación CAMP v1.1. nCAMP no tenía la intención de ser un sistema PaaS útil sino, en cambio, actuar como un vehículo para probar los conceptos y construcciones de la especificación CAMP. nCAMP presenta un sistema simple que usa Tomcat y MySQL para admitir aplicaciones web basadas en Java Servlet que pueden usar MySQL como base de datos.
Proyecto Solum
Solum es un proyecto de Stackforge relacionado con OpenStack diseñado para hacer que los servicios en la nube sean más fáciles de consumir e integrar en el proceso de desarrollo de aplicaciones de los desarrolladores. El modelo de recursos y el esquema del plan de Solum se basan en CAMP, pero no cumplen completamente con CAMP. Actualmente se está trabajando para proporcionar una API adicional compatible con CAMP [4] además de la API nativa de Solum.
Apache Brooklyn
Apache Brooklyn es un marco para modelar, monitorear y administrar aplicaciones a través de planos autónomos. Los planos de Apache Brooklyn cumplen con el borrador de revisión pública 01 de CAMP v1.1.
Notas
- ^ Gestión de aplicaciones en la nube para plataformas versión 1.0, agosto de 2012. https://www.oasis-open.org/committees/download.php/47278/CAMP-v1.0.pdf
- ^ InfoQ, "CAMP 1.0 - An Open API for PaaS Application Management", 31 de agosto de 2012. http://www.infoq.com/news/2012/08/CAMP-PaaS
- ^ 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
- ^ Soporte API CAMP 1.1. https://blueprints.launchpad.net/solum/+spec/solum-camp-api