Reference Architecture for on site deployment for internal and external use (own public and private cloud).

Not applicable

Hi,

I am looking for building API integration layer to expose APIs to Internal and External Apps (Developers).

For this matter, as per company Security policy, External Access GW shall be on our Public cloud, (DMZ), whereas Internal GW shall be place on Internal Cloud (network) with no access from Internet.

However, back-end API integration layer shall be common, so integration to back-ends happens only once ( as well as throttling is done centrally towards back-en systems).

I'm attaching high level diagram to your reference.

Please suggest how Apigee Edge topology would look like.

Thanks,

Vaidotas

5825-apitargetarchitecture.jpg

0 3 1,560
3 REPLIES 3

You do not show arrows in your diagram to indicate which parties are clients that initiate requests, and which are services that receive requests. But from your description I understand that the things labeled "Internal Apps" and "External Third parties" are both clients - request senders.

Apigee Edge is well suited to satisfy your requirements. Apigee Edge today is installable on your own networks, and is a distributed system. You could install Apigee API Gateways in the DMZ as well as in the internal network, to satisfy your requirements. All of these gateways would be managed as one distributed system by a central management "control plane". You can have as much redundancy as you like in the various layers. This is a very typical deployment for Apigee customers.

There are options. One option might be to manage a single layer of Apigee Edge gateways, located on the internal network. You note that the company security policy dictates that "External Access GW shall be on our Public cloud, (DMZ)". This sounds reasonable, but it raises the question: what is the purpose of the External Access GW? If the purpose is only to terminate TLS and verify client-side certificates, you can do that with any number of products, including nginx. That may be sufficient to satisfy your requirements. If the EAGW validates the client authentication, then it could proxy to the API Gateway which is further inside the company network.

Not applicable

Thanks for the reply.

Sorry for not using arrows, but your guess regarding clients is correct.

To be precise, External Access GW shall have client authentication/authorization, API publishing/subscription management and sandbox for external Developers who wish to subscribe, use and try our APIs.

Accordingly, Internal API GW will have the same functions as external but for Internal developers.

However, all API calls (from external and internal apps) shall be managed by common API integration layer which talks to back-end systems. API integration layer will do throttling, load balancing, stats and charging for all API calls. So any back-end API is wrapped/connected once and throttled in one central place.

The reason why we wish to have 2 Access Gateways is because for internal Apps, we will expose thousands of APIs with less security requirements and for External world, only limited number of APIs is relevant but with more tight security.

I hope Apigee has a solution for that.

@Vaidotas Abaravicius I am trying to understand w.r.t to Apigee Component Architecture.

When you say External API access manager - What all components are part of it ?

and same for API Integration Layer ?