[Apiman-user] apiman Production Deployment

[Ashish Patel]

Hi Eric,

In addition to below doubt over "Two Logical API Gateway", have got proposed deployment diagram - can you please review and suggest ?

http://postimg.org/image/qzll2wwhz/

Thanks & Regards,
Ashish Patel

-----Original Message-----
From: Ashish Patel
Sent: 14 June 2016 11:02
To: 'Eric Wittmann'; apiman-user at lists.jboss.org
Subject: RE: [Apiman-user] apiman Production Deployment

Thanks Eric, this helps a lot.

We would go with  Two "logical" API Gateways, as it gives more flexibility. One Doubt: 1. UI will be only one right - be @On Premise / On Cloud.

With single "logical" API Gateway, more concerned over Cloud<->OnPremise Network glitches, may become bottleneck for lot of DB/ES calls (at least for one gateway).

Thanks & Regards,
Ashish Patel
(M) +91 93270 15128

"Scientists investigate that which already is;Engineers create that which has never been." - Albert Einstein.



-----Original Message-----
From: Eric Wittmann [mailto:eric.wittmann at redhat.com]
Sent: 13 June 2016 21:32
To: Ashish Patel; apiman-user at lists.jboss.org
Subject: Re: [Apiman-user] apiman Production Deployment

Hi Ashish.

Sorry for the delay in my response.  I'll do my best to answer your
questions.

> 1. We want to have single API Manager for our consumers in "on-premise"
> and "cloud" (AWS/Azure..etc). So, can we deploy couple of instance of "
> Apiman Gateway" in on-premise and couple of on cloud ? If yes, what
> would be possible deployment architecture ? (best place to put RDBMS
> on-prem/cloud, best place to put keyclock server/ ES server..etc ?)

There are a very large number of choices here!  It depends a lot on
exactly what you're trying to achieve.  Two different configurations
jump to mind.

Config 1 - A single "logical" API Gateway

In this configuration, every API Gateway node (regardless of whether it
is on-prem or in the cloud) shares a common data store.  This allows
every node to service the *same* set of APIs.  In this case the single
gateway storage (database or elasticsearch) will need to be accessible
by all gateway nodes.

In the UI, there is only *one* gateway, so there are no extra steps that
API developers need take when publishing APIs.  However, every Gateway
node must be able to access every back-end endpoint at the same URL.


Config 2 - Two "logical" API Gateways

In this config, the on-prem gateway node(s) and the in-cloud gateway
node(s) each have their own gateway storage (database and/or
elasticsearch).  When set up this way, the API Manager must be
configured with *both* gateways, and each gateway should have a sensible
name, such as "On Premise Gateway" and "Cloud Gateway".

In the UI, the API Developers will need to choose which of the two API
Gateways their API should be published to (they must choose *at least
one* gateway).  This allows different gateways to service different
APIs, offering more flexibility.

> 2. production guide having wildfly version, however we would prefer
> tomcat / vert.x, any specific guide changes for tomcat / vert.x ?

We only have documentation for Wildfly at the moment, but if you wish to
use Tomcat it should be relatively simple to extrapolate the
documentation to that platform.  The vert.x implementation is
experimental at this point, and should not be used in production.

> 3. Can we have companies using apiman on production ? any benchmarking
> stats and case study material ?

I'm sorry to say that we don't currently have reference users or
production benchmarks yet.  These materials will surely be coming in the
future as the project matures.

Thanks!

-Eric

Disclaimer: This message may contain privileged and confidential information and is solely for the use of intended recipient. The views expressed in this email are those of the sender and not Future Group's. The recipient should check this email and attachments for the presence of viruses. Future Group accepts no liability for any damage caused by any virus transmitted by this email. Future Group may monitor and record all emails.