Cloud Foundry a expliqué

Je suis un développeur sur Cloud Foundry -- et oui, Cloud Foundry est en effet un peu nébuleux (no pun intended). J'espère pouvoir aider à clarifier un peu les choses.

Cloud Foundry est un plate-forme en tant que service, mais il a besoin d'un l'infrastructure en tant que service dessous. Cloud Foundry prend en charge vSphere, vCloud, OpenStack, et Amazon AWS que les infrastructures par le biais de la BOSH outil. La plupart des développeurs d'applications web ne se soucient pas de tout cela, mais c'est vraiment cool pour les personnes qui ont à vous inquiéter de la taille de l'infrastructure.

Dire que vous êtes en charge de l'informatique de AcmeCorp. Vous avez 50 000 employés qui utilisent tous les internes du service web, Fizzbuzz, pour les aider à faire leur travail. À l'appui de tous les salariés, vous avez besoin des dizaines de cas de la Fizzbuzz application s'exécutant sur plusieurs machines avec des processeurs puissants et beaucoup de mémoire, et vous avez besoin d'énormes quantités d'espace disque pour stocker les informations générées par le Foo, Bar et Baz applications que vous utilisez en interne, aussi. Vous avez déménagé bien au-delà de ce que vous aurez à gérer sur votre propre serveurs lames, si vous décidez de louer un centre de données.

Malheureusement, AcmeCorp est horriblement dysfonctionnel. Le ministère des finances a un énorme dire dans quel centre de données que vous utilisez, et tous les ans en couple elles vous font passer d'un datacenter à l'autre. Tous les ans en couple, vous disposez de plusieurs semaines de temps d'arrêt pendant votre ingénieurs essayer de corriger les bugs dans Fizzbuzz exposés par commutation entre vSphere, vCloud, OpenStack, ou quoi que ce soit.

Si votre ingénieurs avaient écrit Fizzbuzz, Foo, Bar et Baz contre Cloud Foundry, plutôt que directement à l'encontre de l'infrastructure sous-jacente, votre temps d'arrêt aurait été réduite au minimum. Vous ne voudriez pas avoir à trop s'inquiéter d'être enfermés dans un particulier datacenter, parce que la couche d'hébergement a été prélevée à l'écart par le Cloud Foundry. Cloud Foundry prend en charge un certain nombre de services, y compris PostgreSQL, MySQL, Mongo, Redis, et RabbitMQ, pour n'en nommer quelques-uns. Si Foo, Bar et Baz utilisation des services offerts par le Cloud Foundry, c'est une chose de moins à s'inquiéter lors de la migration entre les infrastructures.

Plus tard en bas de la route, vous vous rendez compte que vous pouvez faire une fortune en vendant des Fizzbuzz comme un service à d'autres grandes entreprises. Vous êtes en très bonne forme pour cela: parce que vos ingénieurs rearchitected Fizzbuzz à exécuter sur le Cloud Foundry, vous pouvez tout simplement déployer Cloud Foundry pour AWS aussi longtemps que cela est nécessaire. Client essayé pendant six mois et a décidé de ne pas renouveler le service? Pas de problème, vous n'avez pas de centre de données des baux à vous soucier -- juste de mettre fin à toutes ces instances EC2 et de progresser. Vous pouvez facilement avoir un déploiement de Cloud Foundry pour chaque instance de Fizzbuzz comme un service, de sorte que les données de vos clients est totalement isolés les uns des autres.

La cerise sur le gâteau, c'est que le Cloud Foundry est open source. Si vous trouvez que ce n'est pas tout à fait adaptée à vos besoins, vous ne devez pas seulement des e-mails de soutien et d'attendre autour pour le Cloud Foundry ingénieurs pour mettre en oeuvre votre rêve fonctionnalité, vous avez la source de trop, de sorte que vous pouvez apporter toutes les modifications dont vous avez besoin. Et c'est disponible sous la licence Apache 2.0, afin de tirer les demandes sont acceptées avec plaisir, mais pas nécessaire.

J'espère que peint un tableau des types de problèmes que le Cloud Foundry en résout. N'hésitez pas à demander pour plus de détails, dans un commentaire, ou vous pouvez consulter le Cloud Foundry liste de diffusion si ça fait plus de sens pour les questions d'avenir.

voudrais ajouter un commentaire au sujet de l'API d'Andy réponse, mais malheureusement n'ont pas assez de réputation pour le faire. Autant je comprends le Cloud Foundry a vraiment pas d'API spécifiques, mais il fournit beaucoup d'informations utiles via des variables d'environnement (par exemple,VCAP_SERVICES, VCAP_APPLICATION, VCAP_CONSOLE_IP, VCAP_APP_PORT), qui peut être consulté à partir de n'importe quelle langue ou de cadre. Alors que beaucoup d'informations à partir de ces variables à l'intérieur de Cloud Foundry, certains d'entre eux peuvent être très utiles. Le principal est VCAP_SERVICES qui fournit des informations sur les services, qui sont liés à votre application.

Par exemple, si je souhaite recueillir des informations sur Azure Cloud instance de Service (par exemple, son ID), sur lequel mon application est actuellement en cours d'exécution, je voudrais utiliser cette classe de Gestion d'Azur Bibliothèque.

À son tour, Cloud Foundry fournit VCAP_APPLICATION env. la variable qui va contenir les champs suivants:

{"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}

Et, enfin, quelques mots à propos de journaux, de surveillance et de diagnostic. Ce n'est actuellement pas mis en œuvre sur le CF PaaS niveau, cependant j'espère que ce sera mis en œuvre (comme c'est vraiment une fonctionnalité utile) et peut-être quelques nouveaux env. variables (dites VCAP_LOGS, VCAP_PERFORMANCE_COUNTERS) seront exposés à nos applications.