Je dirai d'avance que je suis l'un des ingénieurs d'origine de Appistry, et maintenant chef de produit. Je vais m'en tenir aux faits techniques. :-)
Comme vous le mentionnez, vous pouvez utiliser Appistry CloudIQ Manager pour simplifier le déploiement, la gestion et le cycle de vie de vos applications et services associés sur l'ensemble de vos serveurs cloud. Le gestionnaire peut le faire avec n'importe quel service arbitraire ou combinaison de service/application, et assurez-vous qu'ils restent opérationnels sur chaque serveur. Le gestionnaire fait évoluer les applications de haut en bas au fur et à mesure que les serveurs vont et viennent. CloudIQ Manager fonctionnera correctement avec Mule et GigaSpaces. Comme pour les autres combinaisons, en particulier pour vos besoins d'évolutivité, et l'intégration d'applications développées dans différentes langues, vous pouvez considérer CloudIQ Engine comme une plate-forme d'application. Le moteur pourrait être utilisé à la place de GigaSpaces, ou en combinaison avec eux, en fonction de la pièce que vous adressez. CloudIQ Engine est un conteneur d'application entièrement décentralisé. Le moteur prend en charge plusieurs langues pour l'intégration, à la fois côté client et côté cloud. Côté client, vous pouvez utiliser Spring et .NET Remoting pour appeler des objets hébergés par Engine (l'appelant et l'appelé doivent être dans la même langue) ou utiliser l'API client CloudIQ (C/C++/Java/.NET/SWIG-wrappable) pour soumettre des demandes avec des flux de processus définis par l'utilisateur, ce qui élimine éventuellement le besoin de l'ESB. Les flux s'exécutent dans le cloud sur Engine et permettent une seule requête pour orchestrer les appels sur plusieurs méthodes. Les méthodes peuvent être dans différentes langues. Côté cloud, vous pouvez déployer des objets Java (POJOs et Spring Beans) et des objets .NET (PONO), ainsi que des bibliothèques C/C++ en tant qu'applications Engine. Les objets Java et .NET peuvent être déployés sans modification. C/C++ (et d'autres bibliothèques binaires) nécessite probablement du code wrapper. Les métadonnées décrivent les stratégies de charge de travail et les autres comportements du côté cloud pour votre code.
Les applications du moteur sont entièrement symétriques. Chaque serveur du cloud exécute votre code d'application. L'équilibrage de charge logiciel intégré dirige les requêtes vers le serveur le mieux à même de gérer le travail. Votre code hérite de l'évolutivité de la plateforme sans modifications de code. Au-delà de l'échelle, votre application obtient également la fiabilité et le basculement automatique sans frais, ainsi que la possibilité de définir dans les métadonnées comment vous souhaitez que votre application agisse en réponse aux défaillances.Le moteur met automatiquement à l'échelle votre code, à moins qu'il ne soit pas adapté aux threads, sur tous les cœurs de processeur disponibles. Si votre code n'est pas thread-safe, CloudIQ peut l'exécuter efficacement, mais au prix de ne pas utiliser tous les cœurs.
Vous pouvez facilement l'essayer. CloudIQ Platform Community Edition permet une utilisation gratuite et illimitée du logiciel sur jusqu'à cinq serveurs et/ou dix cœurs de traitement (y compris la production). L'édition communautaire est disponible sur Appistry Peer2Peer (enregistrement requis): Appistry Peer2Peer
Client Appistry Presidio Health exécute des applications Java CloudIQ Engine sur GoGrid avec un grand succès. Il y a un webinaire et une étude de cas avec une discussion technique ici (enregistrement requis): Appistry Resource Library
Bonjour. Merci pour une réponse fantastique. Quelques suivis: 1. En utilisant Appistry, avec quelle rapidité une application peut-elle être intégrée (temps approximatif pour un développeur - est-ce une heure, un jour ou plus?). 2. Si nous sommes à bord de la demande d'un partenaire, avons-nous besoin de leur code source? 3. Une fois l'application liée, disposez-vous d'un outil de gestion des abonnements pour permettre à un utilisateur final de s'abonner rapidement à une application? Merci encore pour une excellente réponse! – kburke
Avec CloudIQ Manager, le transfert des services/applications peut prendre moins d'une journée. Cela devient plus complexe si un service ne peut pas s'exécuter de manière distribuée ou est configuré manuellement. Nous avons des modèles pour des choses comme Tomcat, Jetty, IIS, etc., et ceux-ci peuvent durer moins d'une heure. Les applications CloudIQ Engine varient. Nous avons eu la logique métier thread-safe des ports d'utilisateurs (dll/so/jar) ou des exes de ligne de commande dans une application cloud entièrement distribuée, de n'importe quelle heure à une journée. Comme pour # 2, nous déployons et exécutons juste les binaires, ainsi vous pourriez les inclure. Je peux répondre à d'autres questions ici: http://www.appistry.com/community – Guerry