Apigee X Deployments Limit 60

[shrenikkumar-s]

Hi All,

As per: https://cloud.google.com/apigee/docs/api-platform/reference/limits

Only 60 total deployments, at most 50 of which can be proxy deployments/environment are allowed and it also says that: These limits are unrelated to your Apigee Pricing. I guess you can't buy more is what it means.

We want to know:

1. Why is this done this way, usually enterprises have 100s of APIs (1000s in some cases) and Apigee Edge did allow/allows up-to 1000 if I'm not wrong.

2. How do we tackle this? We're trying to logically combine the backend APIs as multiple proxy endpoints within one Apigee API Proxy (API proxy endpoints limit: 5), each endpoint can have multiple operations (theoretically I can have 50*5=250 basePaths with this approach, practically we can't put all together like this, some may have 1, some 2 and some 5 proxy endpoints). An example:

API Proxy: Enterperise-Management
  Proxy endpoints
  1. UserManagement:
  Operations:
    1. FetchUser
    2. CreateUser
    3. UpdateUser & so on (there is no hard limit on this)
  2. EmployeeManagement
    1.
    2. & so on
  3. CustomerManagement
  4. StoreManagement
  5. AppManagement

3. Another option is at environment level to have multiple dev, test, etc environments and proxies lie there will be different. But this involves same Shared-Flows to be deployed in multiple dev, test, etc environments and that again we lose "some" quota of deployments. And this needs to be bought beyond a point if I'm not wrong. More environments mean more management (CICD, Logging, etc).

I welcome some expert opinions on how best would you tackle this, I'm sure as always I'll find some great answers here- TIA.

Deployed API proxies plus shared flows per environment. Does not apply to Configurable Proxy Environments

60 total deployments, at most 50 of which can be proxy deployments Examples of good configurations: 50 proxies, 10 shared flows 30 proxies, 30 shared flows 5 proxies, 55 shared flows Examples of bad configurations: 55 proxies, 5 shared flows 51 proxies

@kurtkanaskie 

@dchiesa1 

[ganadurai · Accepted solution]

1. Agreed. This is a big shift from CG Apigee to X/Hybrid.
The new revised architecture (X/Hybrid) addresses one of the primary ask from the customer base, to minimize the scale-up time to react to spike in request volume. So when the deployed units (proxies and sharedflow) is under a limit, the components scale-up faster to take up the spikes.

Product team is aware of the challenges for customers with high number of proxies and they are working on revising these limits and coming up with a solution to handle the sharding of proxies across environments. ( **Note: This is not an official statement, wait for Product announcements as it becomes available)

2. Your proposed solution will work. You can also have a single ProxyEndpoint and have condition based flows, so you can go beyond the 5 endpoint limits within a proxy. The only downside to this approach is you will not get analytics at a granular level.

3. Not a good solution as you scale-out for more proxies in the future. And there is a current limit of 85 environments per org. 

Thanks. 

[shrenikkumar-s]

+
@Renuka_atnoor 

@Manisha_Chennu 

@anillaudiya 

@Peeyush_Singhai 

@Harish123 

@Navya_pati 

[ganadurai · Accepted solution]

1. Agreed. This is a big shift from CG Apigee to X/Hybrid.
The new revised architecture (X/Hybrid) addresses one of the primary ask from the customer base, to minimize the scale-up time to react to spike in request volume. So when the deployed units (proxies and sharedflow) is under a limit, the components scale-up faster to take up the spikes.

Product team is aware of the challenges for customers with high number of proxies and they are working on revising these limits and coming up with a solution to handle the sharding of proxies across environments. ( **Note: This is not an official statement, wait for Product announcements as it becomes available)

2. Your proposed solution will work. You can also have a single ProxyEndpoint and have condition based flows, so you can go beyond the 5 endpoint limits within a proxy. The only downside to this approach is you will not get analytics at a granular level.

3. Not a good solution as you scale-out for more proxies in the future. And there is a current limit of 85 environments per org. 

Thanks. 

[shrenikkumar-s]

Hi All

How are enterprises with Apigee X license are handling it today? Any guidelines from Google on this? Request some suggestions on this please.

@ganadurai 

@dchiesa1 

@kurtkanaskie 

@Sai Saran Vaidyanathan

@Siddharth Barahalikar

Request your inputs & opinions- thanks a lot.

[benouarred]

Hi,

it is not a real problem, since it can be resolved technically.

Meaning when you see that you are getting close to the limit, you provision a new env if you still have more env available.

You can start by provisioning only one env per stage (1 dev , 1 uat, 1 stg .... and so).

[shrenikkumar-s]

Yes but the entitlement comes with a limited number of environments.

[kurtkanaskie · Accepted solution]

For the time being you'll have to manually "shard" your environments to support additional deployments (e.g. test-1, test-2, prod-1, prod-2). You'll need to have sufficient entitlements.

Apigee is addressing this limit using "Deployment Groups". In essence, you will be able to deploy proxies to an environment without concern for the 50 deployment limit. When the number of deployed proxies in an environment exceeds 50, a new deployment group will be created behind the scenes and the proxy will be deployed there.

The ultimate limit for deployments in an organization is the maximum number of environments times 50 (85 * 50 = 4250).

This feature is scheduled to be available in H2 2023. Not exactly sure how the pricing will be represented, but essentially you will have the same capacity as you have now based on your number of environment entitlements.

[shrenikkumar-s]

Thanks for the response @kurtkanaskie , very much appreciated 🙂

[shrenikkumar-s]

When sharding the environments in production, we're using prd1 & prd2. However, we don't want to have 2 different hosts/environment information in the URL given to consumers.
Is there a best practice/solution around this?

One solution we're thinking of is to create a Router Proxy and deploy in prd1. Based on KVM values it identifies whether the called proxy is in prd1 or prd2 & routes.

if (kvm.prd1.proxy_basepaths.includes(proxyBasePath)) {
call the proxy using LocalTargetConnection;
} else {
call the proxy using HTTPTargetConnection;
}
This proxy is expected to handle load of ~100 proxies (let’s say 500 operations) in prod since every single request will go through it. Personally not sure if that's a good solution. What do you think of this or do we've better, simpler solutions around this?
PS:
In non-prod we've used the environment info in the WAF URL and WAF routes it to Apigee environment using that info in rules.
https://waf_host/test1/apiBasepath/resource
https://waf_host/test2/apiBasepath/resource

@kurtkanaskie 
@dknezic 

[dknezic]

You shouldn't have to worry about different hosts.. You will create an environment group such as "prd", and this will be mapped to your environments (prd1, prd2, etc). It's the environment group that provides the host mapping ie that single host for your API consumers.. it will then automagically route the request to the appropriate environment and API proxy based on the path.

https://cloud.google.com/apigee/docs/api-platform/fundamentals/environments-overview

https://cloud.google.com/apigee/docs/api-platform/fundamentals/environmentgroups-working-with