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(a)redhat.com&gt;, 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@redhat.com] > Sent: 15 June 2016 23:51 > To: Ashish Patel; apiman-user(a)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(a)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@redhat.com] >> Sent: 13 June 2016 21:32 >> To: Ashish Patel; apiman-user(a)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.