Good question!
There's no technical reason why Apigee Edge could not be the host for orchestration logic. Edge is a general-purpose API server, and is designed to handle logic and routing. It will work just fine, technically speaking.
If you are comfortable coding your orchestration logic in one of the forms that Apigee Edge supports - either in JS callouts, in nodejs, in Java callouts, python, or even in XSLT - then.... by all means, go ahead and do it!
On the other hand if your ESB + SOA practice is mature, if your team knows how to use the tool you have, and is comfortable with using it, then,..... stay with what you've got. It's working, why change? Why introduce disruption?
There are possible good reasons for change, of course. There are reasons you may wish to divest from your ESB , and migrate work and focus to Apigee Edge. I can think of these examples:
- to reduce architectural complexity. Eg, one system to deploy to. And this thereby increases speed and agility.
- to reduce costs - either hard costs or soft costs associated to running the system.
- to reduce focus on system-to-system integration tasks, and emphasize apps and experiences. Eg, experienced people may be thinking "all our systems must enforce schema validation for inbound messages." Yet, that may be unnecessary. Specifying schema for every message may simply be overkill. Maybe YAGNI.
- to take advantage of the cloud-hosted availability of Apigee Edge.
...or maybe some combination of those factors, with others.
But, probably the most important factor is "productivity" - what combination of tools and systems allows your team to be most effective delivering on their goals?
LinkedIn
Twitter
