Is there a best practice for applying traffic isolation packs?

There's not much detail or documentation on traffic isolation packs (TIPs) except in the specs found here: https://apigee.com/about/specification-sheets which states:

"Apigee Edge Cloud Traffic Isolation Pack enables API runtime traffic separation by Apigee Edge Organization or Environment."

Lets say I have 2 TIPs and a 2 region deployment using a typical org and env setup as described here: https://community.apigee.com/questions/22800/how-have-you-setup-your-orgenv-combos.html, what is the best practice for applying TIPs and do regions affect the count for a TIP?

Common sense tells me I should use a TIP for my production org and live environment spanning multiple regions. Similarly, it makes sense to use a TIP for my non-production org and performance environment, also spanning multiple regions.

2 5 2,462
5 REPLIES 5

Good question!

I'm interested in the discussion. Here's my opinion.

There is no "best practice" in the general sense. TIPs allow customers to isolate traffic to insure there is no noisy-neighbor effect when one subset of traffic ramps up unexpectedly.

Your common sense makes sense, I suppose. But it does not apply universally. For example, let's suppose there is no need to run high-stress load tests in the non-production organization and environment. In that case, there's really no need to provision a TIP to separate production traffic from non-production traffic.

In all cases, in the Apigee Edge cloud, the gateways autoscale. This isn't definitional, but here's basically how it works: Suppose the MPs can serve 1000tps with 2 gateways and the clients in your system increase load to 3500 tps. Apigee Edge will increase the number of gateway machines automatically to satisfy that need. When the load subsides below 800tps, then the number of gateways will be reduced to 2 again.

Autoscale is "free" ; there is no charge to the customer for this "elastic" behavior.

If for some reason a customer wants that autoscale to apply to different subsets of load, then TIPs are the tool to allow that.

Why would you ever want to do that? Simple: because autoscale is not instantaneous.

Suppose you have a load that ramps from 100tps to 4000tps in 20 seconds. That's a steep ramp and it will take some time (and exactly how much time is not defined) for the autoscale mechanism to add gateways to compensate. During that adjustment time, machine resources (memory, cpu, IO) can be under contention, and as a result, some requests may be served with a latency that is outside the desired service level objective (SLO). (For example, 350ms). If you have multiple subsets of load consolidated in one autoscale group, then an increase in load in just one of the subsets, can cause increased latency in all of those subsets, due to the contention for shared machine resources.

Using a TIP means one subset of load will be isolated from another, and that phenomenon won't occur.

Keep in mind that in enterprise Apigee Edge SaaS systems, each customer is isolated from another, so there is no need for a customer to license a TIP to be protected from "some other customer".

Thanks, I get the point regarding auto-scaling, but I'm not sure I understand using TIPs for different subsets of load. Are you implying creating an environment for mission critical APIs deployed to an org / env and applying a TIP to just that org / env?

Are there any restrictions on the use of TIPs, by region, by org or by env?

Are you implying creating an environment for mission critical APIs deployed to an org / env and applying a TIP to just that org / env?

Nope. My view that there is no best practice in the general sense. And also, every API is "mission critical" - there are no extraneous APIs. The key point is that there may be subsets of load that are sensitive to latency increases. In that case, a TIP can help isolate load.

Right - all APIs are created equal, but some APIs are more equal than others 🙂

Isolating those "sensitive" APIs could be done via an org/env with a TIP (e.g. IoT APIs).

Here's a configuration that isolates production traffic from all other traffic and environments.

Note that a TIP is required for each region.

5623-screen-shot-2017-09-11-at-100244-am.png