Modeling "Organizations" in Edge

Hi,

What are some of the best practices around creating "organizations" in Edge? We are a large organization having myraid teams using APIGEE for Dev, QA, Stage and Prod.

Model-1: Organizations O1, O2, O3, O4 for all teams.

All teams use O1 for Dev, O2 for QA, O3 for Stage and O4 for Prod

Model-2: Organizations OX1, OX2, OX3, OX4 for B2C team and OY1, OY2, OY3, OY4 for B2B team

Appreciate if the pros and cons could be discussed. thanks.

0 1 199
1 REPLY 1

GREAT Question. I would like to invite practioners such as @Christin @zzz_srichardson@apigee.com and @davidwallen1 to contribute their opinions.

My opinion is that the best approach is to have a single organization for production APIs for each company. You may have multiple distinct environments for different teams within the company, and multiple distinct non-production organizations supporting the teams. But a single production-use organization is probably best. Here's why:

  • Tokens are known within an organization. If team 1 and team 2 expose APIs , and an outside developer wants to build an app that consumes those APIs, then the app shouldn't need to maintain distinct tokens for distinct APIs. Ideally the app just gets one client id + secret pair, and at runtime can get one token, which allows the app to invoke any of the exposed APIs. If you have multiple production organizations, this isn't possible. In the multi-organization case, you will need to provision multiple client id+secret pairs for each app that consumes APIs exposed by different teams. This is an anti-pattern, an example of "inside out thinking", by which I mean the needs inside the organization are prioritized over the needs of those outside the organization. The single-organization approach is "outside-in" thinking. Much preferred.
  • today Apigee Edge allows a developer portal to serve ONE Apigee Edge organization. If you have multiple distinct production organizations, you will need multiple distinct production devportals, one for each organization. Not optimal. Developers will need to register and signin to each one, to track app keys across those multiple properties, and so on.
  • CI/CD for a single production organization is simpler than managing CI/CD for multiple distinct production organizations.

You may imagine there might be downsides. For example, maybe the APIs for team 1 are high volume, and team 2 is concerned that having its APIs hosted in the same organization as those of team 1 will cause the service-level for team 2 APIs to drop. Or maybe you imagine there are performance limitations pertaining to an organization.

Those factors will not affect you.

  • First, Apigee Edge SaaS uses an auto-scaling system so that if the call volume is high, more resources are automatically deployed to handle the load. In general you don't need to be concerned about one team affecting another.
  • In cases where one team's APIs may encounter severe spikes in load, you may want to isolate traffic. In such cases, you can isolate APIs from different teams using environments and the "traffic isolation pack" option for Apigee Edge Saas.
  • There is no practical limitation to the traffic throughput you can attain with a single organization.

My strong recommendation is to use a single production organization.

There are reasons you might want to isolate into different organizations:

  • You have regulatory barriers, or other business separation requirements, that require that some team members are not permitted to view analytics for APIs from other teams. If you use a single Org, team members will be able to view analytics for ALL APIs exposed in that org. If you don't want this, you will need separate organizations.
  • You want to preserve business independence and want to separate the operations of different teams completely.

There may be other reasons. In general, though, the single-organization for production use is the best practice.