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(a)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(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(a)ihsmarkit.com> wrote:
Hi Marc,
Have you benchmarked apiman gateway performance against the 3scale gateway?
Thanks,
David
*From:* apiman-user-bounces(a)lists.jboss.org [mailto:apiman-user-bounces@li
sts.jboss.org] *On Behalf Of *Marc Savy
*Sent:* Wednesday, May 10, 2017 9:25 AM
*To:* Donovan Muller
*Cc:* apiman-user(a)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(a)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/api
man/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/re
d-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(a)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.