[Apiman-user] Future of APIMan (in the context of recent announcements)?
Marc Savy
marc.savy at redhat.com
Sat May 20 15:34:22 EDT 2017
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 at 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 at redhat.com]
> *Sent:* Friday, May 19, 2017 8:15 AM
> *To:* David Rush
>
> *Cc:* apiman-user at 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 at ihsmarkit.com> wrote:
>
> Hi Marc,
>
>
>
> Have you benchmarked apiman gateway performance against the 3scale gateway?
>
>
>
> Thanks,
> David
>
>
>
> *From:* apiman-user-bounces at lists.jboss.org [mailto:apiman-user-bounces at li
> sts.jboss.org] *On Behalf Of *Marc Savy
> *Sent:* Wednesday, May 10, 2017 9:25 AM
> *To:* Donovan Muller
> *Cc:* apiman-user at 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 at 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 at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170520/a03a512e/attachment-0001.html
More information about the Apiman-user
mailing list