web applications - que - Cloud Foundry explicó

heroku

Question

Así que he estado leyendo en Cloud Foundry y todavía estoy confundido en cuanto a lo que es. Aquí está mi opinión de todos modos en PaaS sobre CF, y con suerte ustedes podrían decirme si estoy equivocado y explicarlo un poco mejor.

Una oferta tradicional de PaaS como Microsoft Azure o Google AppEngine proporciona una plataforma completa para desarrollar, probar, alojar y administrar su aplicación web. Sin embargo, debe usar su API y estar restringido a los servicios que ofrecen y a los idiomas / marcos que admiten.

Cloud Foundry parece ser una especie de "intermediario", por lo que permite que su aplicación use servicios de muchas nubes públicas. ¿Cómo logra esto? ¿Hay una única API que utilizas, algo así como LibCloud o JCloud? ¿Puede usar un servicio de un proveedor y otro de otro proveedor, por ejemplo? ¿Ofrece Cloud Foundry en sí mismo algún servicio, o es simplemente un intermediario que le permite migrar fácilmente de una plataforma a otra, y usar diferentes combinaciones de servicios de diferentes proveedores en una sola aplicación?

Answer 1

Ciertamente, CF es una capa de abstracción entre su IaaS (servidores, almacenamiento y redes) y su aplicación, que le ofrece portabilidad para mover su aplicación entre nubes públicas y privadas, pero también es mucho más:

1. Una plataforma basada en contenedores altamente escalable horizontalmente

Las aplicaciones se ejecutan en contenedores, lo que permite una mejor administración de recursos que la asignación de aplicaciones a hosts (VM). Warden / Garden es la tecnología de contenedor nativa de CF aunque Docker también es compatible en versiones recientes.

2. Una plataforma de autocuración que proporciona múltiples capas de HA para su aplicación

El sistema de gestión de la salud rescata instancias de aplicaciones fallidas, hosts de contenedores, procesos de plataforma y máquinas virtuales, sin interrupción. El soporte de zona de disponibilidad proporciona HA en la capa de infraestructura. Las actualizaciones continuas y las implementaciones canarias permiten un tiempo de inactividad cero incluso durante las implementaciones o las actualizaciones de la plataforma.

3. Un tiempo de ejecución de aplicación políglota obstinada

Al usar la construcción heroku "buildpack", el lenguaje de la aplicación se detecta automáticamente y la pila de tiempo de ejecución apropiada se construye sobre una imagen del sistema operativo vanilla, lo que permite a los desarrolladores centrarse en escribir código.

4. Aprovisionamiento a pedido del desarrollador de servicios de datos con estado

Los desarrolladores pueden autoabastecer una porción de un clúster MySQL, RabbitMQ, Redis, etc. con uri / credenciales inyectadas automáticamente en el entorno de su aplicación.

Answer 2

Soy un Promotor Defensor de Cloud Foundry y quiero agregar un poco a la respuesta de Mark para centrarme en algunos de los otros detalles que mencionaste en tu pregunta original.

En primer lugar, mencionas GAE y Azure. Ambas tienen ciertas limitaciones: GAE lo limita a determinados lenguajes y API, por ejemplo. Tampoco son de código abierto. CF es extensible (la nueva versión tiene soporte para buildpack, por ejemplo, lo que le permite elegir "cualquier" tiempo de ejecución de idioma), y puede elegir ejecutarlo donde lo desee.

Mark menciona 4 proveedores IaaS podemos ejecutar CF en la actualidad, pero suponiendo que el IaaS en cuestión (digamos que incluimos Azure, CloudStack, Google Compute Engine etc. como objetivos futuros) puede admitir un pequeño número de lo que llamamos Cloud Provider Interfaces (CPIs ) luego puede implementar Cloud Foundry en esas infraestructuras también.

Usted pregunta cómo es posible usar los servicios de diferentes proveedores. Al igual que Heroku, la próxima versión de Cloud Foundry (.com) admitirá un "mercado" donde puede agregar funciones de proveedores adicionales, y si está ejecutando su propia instancia de Cloud Foundry, puede elegir qué servicios implementar y conectarse a sus aplicaciones. .

Es genial :-) ven a hablar con nosotros en la lista de correo si quieres saber más!

Answer 3

Soy un desarrollador en Cloud Foundry, y sí, Cloud Foundry es de hecho un poco nebuloso (sin juego de palabras). Espero poder ayudar a aclarar las cosas un poco.

Cloud Foundry es una plataforma como servicio , pero necesita una infraestructura como servicio debajo de ella. Cloud Foundry es compatible con vSphere , vCloud , OpenStack y Amazon AWS como infraestructuras a través de la herramienta BOSH . A la mayoría de los desarrolladores de aplicaciones web no les importa nada de eso, pero esto es realmente genial para las personas que tienen que preocuparse por una gran infraestructura de TI.

Supongamos que está a cargo de TI para AcmeCorp. Tiene 50,000 empleados que usan su servicio web interno, Fizzbuzz, para ayudarlos a hacer su trabajo. Para admitir a todos los empleados, necesita docenas de instancias de la aplicación Fizzbuzz ejecutándose en varias máquinas con potentes procesadores y mucha memoria, y necesita enormes cantidades de espacio en disco para almacenar la información generada por las aplicaciones Foo, Bar y Baz que usa internamente, también. Se ha movido mucho más allá de lo que le gustaría administrar en sus propios servidores blade, por lo que decide arrendar un centro de datos.

Desafortunadamente, AcmeCorp es terriblemente disfuncional. El departamento de finanzas tiene una gran influencia en el centro de datos que utiliza, y cada dos años lo hacen cambiar de un centro de datos a otro. Cada dos años, tiene varias semanas de inactividad mientras sus ingenieros intentan solucionar los errores en Fizzbuzz expuestos al cambiar entre vSphere, vCloud, OpenStack o lo que sea.

Si sus ingenieros hubieran escrito Fizzbuzz, Foo, Bar y Baz contra Cloud Foundry en lugar de directamente contra la infraestructura subyacente, su tiempo de inactividad se habría minimizado. No tendría que preocuparse demasiado por estar encerrado en un centro de datos en particular, porque esa capa de alojamiento ha sido abstraída por Cloud Foundry. Cloud Foundry también admite cierto conjunto de servicios, incluidos PostgreSQL, MySQL, Mongo, Redis y RabbitMQ, por nombrar algunos. Si Foo, Bar y Baz utilizan los servicios proporcionados por Cloud Foundry, esa es una cosa menos de la que preocuparse cuando migra entre infraestructuras.

Más adelante en el camino, te das cuenta de que puedes hacer una fortuna vendiendo Fizzbuzz como un servicio a otras grandes empresas. Está en muy buena forma para esto: debido a que sus ingenieros han rediseñado Fizzbuzz para que se ejecute en Cloud Foundry, simplemente puede implementar Cloud Foundry en AWS durante el tiempo que sea necesario. El cliente lo probó durante seis meses y decidió no renovar el servicio. No hay problema, no tiene que preocuparse por ninguna concesión de centro de datos, simplemente finalice todas las instancias de EC2 y continúe. Puede tener fácilmente una implementación de Cloud Foundry para cada instancia de Fizzbuzz como servicio para que los datos de sus clientes estén totalmente aislados entre sí.

La guinda del pastel es que Cloud Foundry es de código abierto. Si encuentra que no se ajusta a sus necesidades, no tiene que enviar por correo electrónico soporte y esperar a que los ingenieros de Cloud Foundry implementen la función de sus sueños. También tiene la fuente para que pueda hacer cualquier cambio que necesites Y está disponible bajo la licencia Apache 2.0 , por lo que las solicitudes de extracción se aceptan con mucho gusto, aunque no son obligatorias.

Espero que represente una imagen del tipo de problemas que Cloud Foundry resuelve. No dude en solicitar más detalles en un comentario, o puede consultar la lista de correo de Cloud Foundry si tiene más sentido para futuras preguntas.

Answer 4

Me gustaría agregar esto como un comentario sobre API a la respuesta de Andy, pero desafortunadamente no tengo suficiente reputación para hacerlo. Por lo que entiendo Cloud Foundry realmente no tiene una API específica, pero proporciona mucha información útil a través de variables de entorno (por ejemplo VCAP_SERVICES, VCAP_APPLICATION, VCAP_CONSOLE_IP, VCAP_APP_PORT ), a las que se puede acceder desde cualquier idioma o marco. Si bien mucha información de dichas variables es interna para Cloud Foundry, algunas de ellas pueden ser bastante útiles. El principal es VCAP_SERVICES que proporciona información sobre los servicios, que están vinculados a su aplicación.

Por ejemplo, si quisiera recopilar información sobre la instancia de Azure Cloud Service (por ejemplo, su ID), en la que se está ejecutando actualmente mi aplicación, usaría esta clase desde la Biblioteca de administración de Azure.

A su vez, Cloud Foundry proporciona VCAP_APPLICATION env. variable, que contendrá los siguientes campos:

{"application_users": [],
"instance_id":"97467a9cf508cb75273284b948b6319b",
"instance_index":1,
"application_version":"330b7caf-50e5-48f4-8792-1c80a90b06f1",
"application_name":"helloworld",
"application_uris":["helloworld.vcap.me"],
"started_at":"2013-07-22 10:58:16 +0300",
"started_at_timestamp":1374479896,
"host":"0.0.0.0",
"port":61014,
"limits":{"mem":256,"disk":1024,"fds":16384},
"version":"330b7caf-50e5-48f4-8792-1c80a90b06f1",
"name":"helloworld",
"uris":["helloworld.vcap.me"],
"users":[],
"start":"2013-07-22 10:58:16 +0300",
"state_timestamp":1374479896}

Y, finalmente, algunas palabras sobre registros, monitoreo y diagnóstico. Esto actualmente no está implementado en el nivel de CF PaaS, sin embargo espero que esto se implemente (ya que es una característica realmente útil) y tal vez un nuevo env. las variables (digamos VCAP_LOGS, VCAP_PERFORMANCE_COUNTERS ) estarán expuestas a nuestras aplicaciones.