Hello RK4. Sorry I couldn't respond yesterday. As noted above, Dino and I touched on the topic of datapower vs. Apigee Edge in our webcast last month.
Performance does tend to be important, but as several other comments point out there are potentially numerous other factors. Most shops that use datapower likely have a sizeable investment in it. Does it make sense to the business to do a wholesale replacement from an ROI perspective? The answer will vary depending on the organization's circumstances.
Performance for data transformations on DataPower vs. Apigee Edge depends on a variety of factors. So, it is hard to make any general observations. For pure XSLT transformations on a datapower hardware appliance, there is likely to be a performance and scalability benefit--that is what the thing was invented for. The moment you move that idea onto DataPower virtual edition, the performance aspects will likely see a more level playing field. But, all of this depends on the size of the XML document being manipulated, complexity of the XML structure, how much of it is being manipulated, how much other security processing is also occurring, etc. For JSON transformations or JSON<->XML transformations, results will definitely vary depending upon the complexity of the data structures and other factors mentioned. So, bottom line, one has to try it with their specific use cases.
Likewise, on the Apigee Edge side, on-premise vs. cloud will likely have different performance characteristics depending upon the on-premise hardware platform that is running the VMs. On Apigee Edge public cloud, the public/free/trial version is probably going to behave differently in most situations than the dedicated/paid/enterprise version. Again, needs to be tested with realistic data sets.
It also depends on what patterns you are using datapower for. Is it your internal ESB? Is it acting as a gateway (security and interface wise) to the internal ESB? Or, gateway in the DMZ? Is it dealing with data transformations whose inputs/outputs are something other than JSON or XML/SOAP? If so, that may not necessarily be the use case that Apigee Edge is targeted towards--Apigee Edge can run custom Java code, so just about anything is possible, but again, not necessarily a targeted use case. Apigee Edge could act as a replacement or alternative gateway to an existing ESB on the internal network. It is also very common to see it as the gateway in a DMZ. It depends who the actors are that are invoking these APIs.
Summarizing, at a very high-level, I've been in datapower shops where I honestly believe Apigee was the better strategic fit and replacing it makes sense. I have also been in shops where keeping datapower to let it do the things it is good at or run a lot of legacy stuff that it made no sense to migrate in the short-to-medium term was the wise choice--but, augment it with the things that Apigee is good at. The webcast describes such a situation--obviously, there are costs associated with this that must be weighed. I could also envision scenarios where datapower is probably the better choice--but, this is an apigee forum.
There is also the API Management angle(governance, life-cycle management, development community, etc), are you using datapower as part of an API Management solution already? Or, it's more traditional use cases? Is Apigee Edge in your organization being used for the full API Management story or is it more about being a datapower replacement? Many ways this can go...ties back to your use cases/requirements and what problem(s) you are trying to solve.
If you have more specific details about your scenario, I'll be happy to respond back.
RCBJ
LinkedIn
Twitter
