Re: [Apiman-user] Future of APIMan (in the context of recent announcements)?

Thanks for the response Marc. I will send over some of our use cases separately. Similar to Donovan I am trying to figure out why the compatibility is being built between the two platforms. What reasons (features or perf) are there to use the apiman gateway instead of just moving to the 3scale solution? Or is this just to provide an easy migration path for current apiman users to 3scale? Like others I was under the impression that apiman was basically moribund, so we began to evaluate options going forward and will need to make a decision soon. I’m pleasantly surprised you guys are still actively working on apiman, but a bit more clarity around Red Hat’s strategy would be great. Thanks again, David From: Marc Savy [mailto:marc.savy@redhat.com] Sent: Friday, May 19, 2017 8:15 AM To: David Rush Cc: apiman-user(a)lists.jboss.org Subject: Re: [Apiman-user] Future of APIMan (in the context of recent announcements)? Hi David, I don't have a comparison like that yet, no. It's going to be challenging to do an apples-to-apples comparison as functionality differs between the platforms. For example, the 3scale gateway doesn't have the concept of custom policy plugins and it doesn't support pluggable/raw metrics. That said: I'm going to try to produce a set of benchmarking scenarios (using Gatling) to sensibly approximate real-world setups. I'll publish those scenarios and numbers once I get access to some benchmarking hardware. As part of the process I want to reach out to the community to help define what we should be putting into those scenarios -- I hope I can include your use-cases into that. For example thought will need to be given to: - What kind of hardware and setups are people using. - What the policy setup is (e.g. JWT auth? rate limiting?) - Which components to use (e.g. Elasticsearch metrics, no metrics, ...) - Logging config - How many users will interact with the system in parallel - What do the payloads look like Naturally, we can have multiple scenarios to cover various setups. Armed with this, I'm hopeful that will provide sufficient information for folk to determine whether it's fast enough, sufficiently low latency, etc, for their use-cases. In general, my experience is that the Vert.x-based gateway has been good -- but that's from running tests on my dev machine, and I realise that's not rigorous, so I want to provide what you're asking for. There's another important aspect unrelated to Vert.x: over time I'll be doing more work to optimise component implementations (e.g. more optimal rate limiting algorithms, etc). This should improve performance on all platforms. Regards, Marc On 18 May 2017 at 20:56, David Rush <David.Rush@ihsmarkit.com<mailto:David.Rush@ihsmarkit.com>> wrote: Hi Marc, Have you benchmarked apiman gateway performance against the 3scale gateway? Thanks, David From: apiman-user-bounces@lists.jboss.org<mailto:apiman-user-bounces@lists.jboss.org> [mailto:apiman-user-bounces@lists.jboss.org<mailto:apiman-user-bounces@lists.jboss.org>] On Behalf Of Marc Savy Sent: Wednesday, May 10, 2017 9:25 AM To: Donovan Muller Cc: apiman-user@lists.jboss.org<mailto:apiman-user@lists.jboss.org> Subject: Re: [Apiman-user] Future of APIMan (in the context of recent announcements)? Hi Donovan, * Will APIMan form some part of the new 3Scale integration As per our blog posts in the past, the aim is to integrate the apiman gateway with the 3scale manager in the community. In the next release I'll hopefully be providing some initial integration for folk to play with, but I'm not in a position to comment yet on fuller integration with the UI, etc -- rest assured as soon as I can, I'll let you all know. Of course, I will forward your interest to the relevant parties (and that of others who contact me -- or have already done so). (more specifically, the on premise solution/OpenShift)? I can't really speak about products, but I will put you in touch with people who can! If not, why the 1.3.0 release (since this adds new features)? Some of this work is setting the ground for future work (including the above), ensuring that we keep the apiman community well-served in terms of gateway bug-fixes, features, performance, etc. The reason for the version number bump is (in part) that some small incompatible changes were introduced -- so, according to semver that requires a minor increment rather than patch. Plus some substantial new features released (apiman Vert.x gateway, headless registry, etc). Regards, Marc On 9 May 2017 at 20:27, Donovan Muller <donovan.muller@gmail.com<mailto:donovan.muller@gmail.com>> wrote: Hi all, Having seen the response (from Marc Savy) on the thread with the subject "Response when gateway cannot connect to the API implementation" about a 1.3.0 release of APIMan (with the vert.x gateway) and then having seen related commits on the GitHub repo (https://github.com/apiman/apiman/commit/d3cedc5e05f143d45df8aa065e61de40b...). I'd just like to ask about the future of APIMan in relation to the 3Scale integration, especially, considering this announcement in relation to OpenShift: https://www.redhat.com/en/about/press-releases/red-hat-introduces-fully-c.... Some questions I have: * Will APIMan form some part of the new 3Scale integration (more specifically, the on premise solution/OpenShift)? * If not, why the 1.3.0 release (since this adds new features)? * If so, what would APIMan be used for? I'm asking this in the context of a financial services organisation needing an on premise OpenShift integrated API Gateway solution. We are currently using APIMan (based on what was done here: https://github.com/openshift/origin-apiman) as a temporary solution until whatever 3Scale on premise solution will be released... Thanks in advance _______________________________________________ Apiman-user mailing list Apiman-user@lists.jboss.org<mailto:Apiman-user@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/apiman-user ________________________________ This e-mail, including accompanying communications and attachments, is strictly confidential and only for the intended recipient. Any retention, use or disclosure not expressly authorised by Markit is prohibited. This email is subject to all waivers and other terms at the following link: http://www.markit.com/en/about/legal/email-disclaimer.page Please visit http://www.markit.com/en/about/contact/contact-us.page for contact information on our offices worldwide. ________________________________ This e-mail, including accompanying communications and attachments, is strictly confidential and only for the intended recipient. Any retention, use or disclosure not expressly authorised by Markit is prohibited. This email is subject to all waivers and other terms at the following link: http://www.markit.com/en/about/legal/email-disclaimer.page Please visit http://www.markit.com/en/about/contact/contact-us.page for contact information on our offices worldwide.