Apigee Organization - Private Cloud- What drives Organization ?

Google Cloud Apigee
1

Understand that Organization An organization is the top-level container in Apigee Edge. It contains all your API proxies and related resources.

Question: what drives Organization ?:

  1. If a Company acquires multiple other companies (5 other acquired company) and due to Governance of 5 different companies I can have 5 Orgs to maintain Multi Tenancy.

  2. In cases where I don’t have such requirements. say instead of 5 Organization. I will have 2 Organization (one for External (B2B) and one for internal (A2A) belong to single Company & in such cases all API and data is transparent..

  3. I can even design Organization based on high volume and low volume ? to have them maintained separately. Is that a correct approach

  4. What could be other best known scenarios.

5.. We do understand that Portal (Drupal Portal) will be per Organization, hence the more the Organization is more is the Portal (1:1 mapping) to maintain, but challenge is I don’t get single view of Customer having them accessing the different Organization. ie I cannot have one Portal for multiple organization correct ?

Whats the best way to design or drive Organization or any other approach you derived number of Organization ?

5.Any more usage of Organization based on practical experience which suits better ?

This is more of Private cloud, hence limitation for Organization does not exists, but need to utilize in better way. Having One Organization (& having one Drupal Portal) will give better view of customer but its not clear on driving factor for Organization..

In case of Private Cloud I can add more Organization in later point post installation, but deriving the best usage is question.

2

First to level set, here is documentation on Organizations and Environments.

https://docs.apigee.com/api-platform/fundamentals/apigee-edge-organization-structure

There are any number of ways you can configure your organization to support API development. The decision depends on a multitude of factors including your software development life cycle, internal team structure, business unit participation, governance, business models, etc. As a result, you have a ton of flexibility to design your organizations as you see fit.

There are however a few best practices to help you keep things simple and help with overall development processes. For example, most organizations only need 2 orgs, 1 for non-production and one for production. In this scenario let’s call them myco-np and myco-prod.

  1. If myco acquires other companies or business units you can decide to either build up new orgs for those companies such as mynewco1-np and mynewco1-prod OR keep them all on your original orgs. (I’ll dive into this more later).

  2. Yes, if you don’t need separate orgs for different business units, best practice is to maintain your two org configuration, again you’d keep myco-np and myco-prod. Internal and External API traffic would be treated the same.

  3. You don’t need to segregate high traffic volumes by org. You can track this activity within analytics inside of a single org. You can do this by application or API key as an example, and determine which APIs are generating the most volumes.

  4. I’ll share a scenario below.

  5. Yes, Drupal and Integrated developer portal maps 1 to 1 to an org. So in our case, myco-prod would be pointed to your dev portal. In most cases, you do not need multiple dev portals, and you don’t need to point a dev portal to your nonprod org.

Even though in private cloud you do have the flexibility to spin up new orgs as you need, again, best practice for private cloud or saas is fairly similar.

My general recommendation is to follow a solution like this:

| myco-np | — | — | --------| | myco-prod | — | — | --------| |
| - | - | - | - | - | - | - | - |
| dev | test | perf | stage | uat | mock | sandbox | prod |

In this scenario you have a non-production org with the environments of dev, test, perf and stage, and a production org with the environments of uat, mock, sandbox and prod.

These environments dictate what activities happen across the company and throughout the development life cycle.

Every business, business unit, partner, or internal / external team can follow the same process. Each application having their own key that can be individually tracked for performance and traffic volume. In addition, you can control API products across the life cycle also with keys, access controls, and depending on your overall code branching strategy. In short, all API development can flow across this workflow fairly easily.

As I said above though, there are numerous scenarios, and elements that might change this picture. But in general, this is a great starting point for your to consider.

1 Like