Guidelines around Virtual Hosts in APIGEE Edge

Hi All,

I am looking for some guidelines/pointers around virtual hosts.

We are using APIGEE Edge SaaS and have two organisations i.e., NonProd and Prod. So far we are creating proxies to expose APIs of a Backend/Target system e.g. target_system1 and we have created virtual host with domain name api-{env}.target_system1.company_name.com.

For an upcoming requirement we will be creating proxies to expose APIs from another Target System e.g. target_system2. So trying to decide whether we should create a new virtual host api-{env}.target_system2.company_name.com or keep using the existing one or create a new one which will handle traffic for all target systems i.e. api-{env}.company_name.com.

I understand that it might be more of a governance question but would like to understand the following  

1. Will it create a single point of failure if we use only one Virtual Host for all target systems. As per my reading on APIGEE docs, APIGEE SaaS has robust DR strategy and datacentre replication. Does that mean that a Virtual Host can never become unavailable?

2. Will be good to know some performance guidelines/KPIs on virtual hosts e.g. If currently its serving 100 requests/second, what happens when the transactions shoots up to 1000 requests/second. Will the Virtual host auto-scale in the background? Will there be any impact on traffic while the autoscaling is taking place? Any links specific to APIGEE Edge KPIs would help.

3. If we go with different virtual hosts, does it mean that load on one virtual host will never interfere on the traffic of other virtual host/s.

Thanks in Advance!

 

Solved Solved
0 1 323
1 ACCEPTED SOLUTION

I've always appreciated a single hostname for all API traffic (api.company.com). It's a very clean way to represent your API program. Of course you can have off shoots of the primary hostname for specific environments (api-dev.company.com). 

With that said, virtual hosts are exactly that - virtual hosts. It will have no bearing on the performance or scalability as long as you remain under the documented product limits.

To answer your questions -
1. No, there is not a single point of failure if you have one virtual host. Virtual hosts should remain available as applicable to your contractual SLA.
2. Virtual hosts are not a component; rather, they are configuration set in the router. You can think about virtual hosts as "listeners". So, no virtual hosts will not auto-scale, BUT the underlying infrastructure (e.g. routers, message processors, etc) WILL.
3. No, again virtual hosts are not components. You can purchase Traffic Isolation Packs if you need dedicated infrastructure for specific environments and/or orgs.

View solution in original post

1 REPLY 1

I've always appreciated a single hostname for all API traffic (api.company.com). It's a very clean way to represent your API program. Of course you can have off shoots of the primary hostname for specific environments (api-dev.company.com). 

With that said, virtual hosts are exactly that - virtual hosts. It will have no bearing on the performance or scalability as long as you remain under the documented product limits.

To answer your questions -
1. No, there is not a single point of failure if you have one virtual host. Virtual hosts should remain available as applicable to your contractual SLA.
2. Virtual hosts are not a component; rather, they are configuration set in the router. You can think about virtual hosts as "listeners". So, no virtual hosts will not auto-scale, BUT the underlying infrastructure (e.g. routers, message processors, etc) WILL.
3. No, again virtual hosts are not components. You can purchase Traffic Isolation Packs if you need dedicated infrastructure for specific environments and/or orgs.