I can gladly put you in touch with people who know and can talk to you about support/product. I can only talk about project in this context.

What reasons (features or perf) are there to use the apiman gateway instead of just moving to the 3scale solution?

The short answer: My view is that that they're different and strongly complementary, rather than competitive. Apiman is a great offering if you want: Java/JVM; custom policy plugins and plugin lifecycle management; a heck of a lot of flexibility in terms of components and platforms, then I think apiman gateway is a great offering.

The long answer:

I encourage you to go and do an analysis to see whether 3scale fulfils your needs, as I'm not an expert on 3scale by any means.

That said, I think the apiman gateway has some very clear features and differentiators which may be valuable *depending on your requirements*. Just off the top of my head, to speak about some of apiman's attributes:

The apiman gateway is JVM/Java based, and can be run on a bunch of different platforms and in a few different ways (Vert.x, Tomcat, WildFly, EAP, Jetty, embedded, ...). 3scale's standard gateway is NGINX/LUA.
Apiman has custom policy policy plugins, with a clearly-defined development and lifecycle management. 3scale doesn't have a concept of policies, plugins or a policy chain; however, customisation can be done via LUA scripting which may be sufficient.

Clearly, if you're a Java/JVM shop; want to do extensive customisation; want a familiar toolchain; want a familiar build and deployment system - then apiman gateway is a strong offering.

Java/JVM offers an impressive ecosystem in terms of tools, libraries, performance, etc.

Ultimately, we can offer practically arbitrary functionality in a flexible way, which is very powerful [if you need it!].
Apiman is supremely flexible; you can swap out almost all components and provide alternative or custom implementations. For example, different rate limiting implementations, different shared state implementations, etc.
Apiman has pluggable metrics [amongst other things], giving you access to raw data that you can do almost anything with (e.g. shove into Elasticsearch, InfluxDB, etc). AIUI, 3scale requires up-front definition of metrics to be collected, so once your decision is made, that's it.
Apiman policies allow mutation of header and body, whereas AIUI, 3scale gateway doesn't presently do body mutation.

There may be some features 3scale gateway that apiman gateway doesn't have -- but I'm just not expert in that software!

Naturally, I encourage you to research your options.

In terms of perf, as I mentioned I don't have numbers yet, but in my experience we've been more than fast enough (especially given that adding extra nodes isn't problematic for most people). More on that to come, of course...

Or is this just to provide an easy migration path for current apiman users to 3scale?

In the community we're looking to provide the ability for the apiman gateway to draw its configuration from 3scale manager/backend, so you can get all of the awesome-sauce of the apiman gateway in combination with the 3scale manager. Importantly, compatibility with the existing apiman UI/Manager is being maintained in these releases.

[Of course, for some users a completely headless operation is what they want, and you can do that easily now].

In the longer term, I hope we will be able to offer deeper integration into the 3scale manager UI side of things. I've already received quite a lot of enthusiasm for that, and the more feedback/demand the better. As I'm the lead for only the apiman gateway, I can't make any commitments on behalf of other projects, but I sense there's a strong case.

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.

I'll contact you off-list to get answers to your other questions.

Ultimately, demand from folk like you is an important factor in driving these decisions :-). So, the feedback I'm getting is really encouraging and *extremely important* to show to the relevant people.

I hope to land the initial 3scale integration I referred to earlier in the next couple of weeks.

Regards,

Marc

On 19 May 2017 at 16:59, David Rush <David.Rush@ihsmarkit.com> wrote:

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@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> 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] On Behalf Of Marc Savy
Sent: Wednesday, May 10, 2017 9:25 AM
To: Donovan Muller
Cc: 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> 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/d3cedc5e05f143d45df8aa065e61de40b441c7fc). 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-containerized-api-management-platform.

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
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.