[Apiman-user] apiman Production Deployment
Eric Wittmann
eric.wittmann at redhat.com
Thu Jun 16 15:05:36 EDT 2016
I think your best bet may be to set up a periodic transfer of metrics
data from the cloud to on-premise so that all your metrics are in a
single ES instance. I believe ES has some tools to help with this, but
I don't have enough expertise in ES to be sure.
As for apiman, at the moment it can only interrogate a single metrics
store for data.
-Eric
On 6/16/2016 11:51 AM, Ashish Patel wrote:
> Cool Thanks Eric.
>
> I have proposed separate ES for cloud gateway to avoid frequent
> cloud<->OnPrem n/w calls. Will API Manager be able to show cloud
> gateway metrics? If Yes, wanted to know how that works.. and if no,
> what are other options to view cloud gateway metrics?
>
> Thanks again,
> Ashish.
>
>
>
> Sent from my phone
> On Eric Wittmann <eric.wittmann at redhat.com>, 16-Jun-2016 2:58 pm wrote:
>
> I think this diagram looks pretty good now! :) I don't think there's
> any issue with having a single Keycloak to support both on-prem and
> cloud. That would make user and realm management much easier,
> obviously.
>
> -Eric
>
> On 6/16/2016 3:54 AM, Ashish Patel wrote:
> > Hi Eric,
> >
> > Oh, yes copy paste. Modified it. Kindly suggest.
> >
> > https://postimg.org/image/ebydokdbl/
> >
> > One specific query on KeyCloak : can we have only one - KeyCloak
> (OnPrem) ? or is it mandatory to keep OnPrem and Cloud ?
> >
> > 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: 15 June 2016 23:51
> > To: Ashish Patel; apiman-user at lists.jboss.org
> > Subject: Re: [Apiman-user] apiman Production Deployment
> >
> > Hi Ashish.
> >
> > I'm a little bit confused by some of the box labeling I think.
> Some of
> > the boxes in the top half of the diagram are labelled "Cloud" when I
> > expected them to be labelled On-Premise. Is that intentional or
> > copy/paste errors?
> >
> > -Eric
> >
> > On 6/14/2016 7:35 AM, Ashish Patel wrote:
> >> 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.
> >>
> >
> > 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.
More information about the Apiman-user
mailing list