[Apiman-user] apiman Production Deployment

[Ashish Patel]

Hi Eric,

No issue with two separate Gateway for API Developers, they shall choose appropriate one. Had query on the overall deployment architecture, sent yesterday on same subject. Appreciate if you can look into it and suggest ?

Thanks & Regards,
Ashish Patel

"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: 14 June 2016 18:26
To: Ashish Patel; apiman-user at lists.jboss.org
Subject: Re: [Apiman-user] apiman Production Deployment

If you choose to go with two logical gateways, then API developers will
need to select one of them (or both) in the API Manager UI.  This allows
the developer to choose which of the Gateways to publish to.

In your described scenario I definitely think I would recommend this
approach.

If you want two separated Gateways but do not want API developers to
have to pick between them, then we would need to find an alternative
solution.  Perhaps something custom - something that sits in between the
API Manager and the (multiple) API Gateways so that when an API is
published, it gets published to both gateways.  That's not something we
support right now.

-Eric

On 6/14/2016 1:32 AM, Ashish Patel wrote:
> 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.
>

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.