Développement Agile et ESB

Question

Je travaille sur le transfert de notre paradigme technologique d'entreprise au développement Agile. Ce fut un processus difficile mais nous y sommes presque! :)

Nous avons des systèmes hérités pour notre gestion de base de données (Access, maintenant porté sur .NET et MS SQL) et nous développons un cadre pour notre vision future. Nous voulons migrer le plus possible vers le web. Mais nous voulons intégrer le système actuel avec celui "à venir". Nous ne chevaucherons pas les tâches et les fonctionnalités. Ma vision est de déplacer toutes les informations de contact sur nos utilisateurs vers une base de données différente, reliant ces "profils" à MS SQL pour leur histoire et leurs informations comptables. Nous garderons tous les systèmes de comptabilité sur l'application de bureau, mais il y a beaucoup plus de fonctionnalités que nous sommes sur le point d'ajouter qui dépendront fortement du web, en particulier Ruby on Rails.

Je suppose que la question est: pourquoi les ESB? Existe-t-il un moyen de créer une architecture SOA sans aller trop loin avec les systèmes ESB complexes? L'idée est de K.I.S.S. en tous cas. Une SOA peut-elle être créée de telle sorte que le bureau/le web/le mobile soient des interfaces, gardant les fonctionnalités sur la logique métier (bien sûr, certaines fonctionnalités devraient être implémentées sur l'interface, mais au strict minimum). Et les ESB correspondent-ils même à une philosophie Agile? Plus je les lis et étudie, moins je le pense! :/

Merci pour vos commentaires! Si vous avez besoin de clarifier, posez quelques questions et je ferai de mon mieux pour le faire! :)

Answer 1

Les ESB s'adaptent bien à l'agilité une fois le cadre/l'infrastructure en place. Vous constaterez que vous pouvez créer un nouveau système en morceaux, exécuter les nouvelles pièces en parallèle avec l'ancien système pendant un certain temps et éteindre graduellement les anciennes parties du système jusqu'à ce qu'il ne reste plus que le nouveau système, et personne ne le fera. jamais connaître la différence

Un SOA de base définit simplement les services au lieu des applications; un ESB gère les services dans les canaux pour cacher les endpoints, rendant les mises à jour et les substitutions beaucoup plus "agiles"

Answer 2

Toute la migration est ce qui m'a amené aux ESBs ... Mais l'idée même d'un ESB semble être complexe à résoudre un problème qui implique environ 30 000 profils! Nous sommes sur le point de connaître une croissance exponentielle (à quelques millions de profils) et il serait peut-être préférable de commencer sur une nouvelle voie. Est-ce facile de lier une entrée qui se trouve sur un DB MySQL aux données stockées sur MS SQL DB? Je ne veux évidemment pas de double entrée, mais il pourrait y avoir une façon plus agile qu'un ESB «entier» ... Je comprends qu'un SOA avec un ESB peut être assez agile en termes de mises à niveau et de substitutions, mais serait-il une exagération? :)

Answer 3

J'ai appris assez rapidement à avoir peur du terme « ESB » comme SITI très surchargée et signifie différentes choses pour différentes personnes (et parfois des choses différentes à la même personne :-))

L'essentiel, naturellement, est de vous demander ce dont vous avez réellement besoin. L'emballage de votre (vos) base (s) de données en tant que service est susceptible d'être un choix judicieux, en particulier si vous avez plusieurs clients pour ces données; vous devrez passer beaucoup de temps à penser à vos contrats et à votre portée, mais agile peut grandement aider ici. La question est de savoir comment ces services sont appelés, et je pense que vous devez évaluer la probabilité que les clients et les services changent et que votre système évolue.

Un bus de service permet de masquer les services de leur client (qui peut être d'autres services) et ce "masquage" peut être relayé vers l'emplacement, le protocole, les formats, les codes, etc. certaines formes d'un bus de service maintiennent également l'itinéraire (ce qui doit être appelé, et quand) mais je n'aime généralement pas l'idée.

donc - la question que vous devez vous poser d'abord, je pense, qu'est-ce que vous avez besoin pour commencer et combien les investissements avant que vous êtes désireux de faire (et peut justifier) ​​

Par exemple, si Au départ, vous êtes satisfait d'une approche plus point-à-point, vos clients peuvent appeler le service directement; à un stade ultérieur, au fur et à mesure que le service évolue, vous pouvez introduire l '«intermédiaire» pour négocier la demande et la réponse (oui - vous pouvez l'appeler ESB si vous le souhaitez).

Alternativement, vous pouvez commencer par un «intermédiaire» de base, de sorte que les clients n'appellent jamais le service directement, mais possèdent seulement les fonctionnalités dont vous avez besoin pour commencer et développer ses capacités sous forme d'exigences; il pourrait bien commencer comme une simple machine d'expédition.

Idéalement, vous devez construire sur un produit qui a de nombreuses fonctionnalités intégrées; BizTalk Server est un bon match si vous êtes sur la pile MS (mais a sa courbe d'apprentissage)

donc - excusez si ce n'est pas une réponse très concrète - mais je suppose que mon point principal est que "ESB" n'a pas à être un surdimensionné, il revient simplement à ce que vous souhaitez avoir au premier jour, et agile (et SOA) aide certainement en vous permettant d'évoluer progressivement plutôt que tout grand big-bang.

(si tout ce qui précède est un non-sens complet ou juste un peu clair, il est à cause du manque de sommeil avec un nouveau-né dans la maison! Excuses :-))