Apigee Overview and Set Up of Apigee X

15 min readOct 1, 2022

With the rapid transition to online platforms, competition among digital businesses is increasing dramatically. It is no longer enough to just use the API, and be able to manage and scale it. So now is time for Apigee X, which speeds up the process of deployment and scaling and is several times faster than other methods. Fast response and efficiency gives Apigee owners an advantage when working with API. Apigee’s main goal is to simplify the digital experience and improve the interaction with the API.

You have data, you have services, and you want to develop new business solutions quickly, both internally and externally. With Apigee, you can build API proxies — RESTful, HTTP-based APIs that interact with your services. With easy-to-use APIs, developers can be more productive, increasing your speed to market.

What is Apigee?

Apigee is a platform for developing and managing APIs. By fronting services with a proxy layer, Apigee provides an abstraction or facade for your backend service APIs and provides security, rate limiting, quotas, analytics, and more.

Making your services available on the web

Companies today want to make their backend services available on the web so that these services can be consumed by apps running on mobile devices and desktops. A company might want to expose services that provide product pricing and availability information, sales and ordering services, order tracking services, and any other services required by client apps.

Companies often expose services as a set of HTTP endpoints. Client app developers then make HTTP requests to these endpoints. Depending on the endpoint, the service might then return data, formatted as XML or JSON, back to the client app.

The client apps that consume these services can be implemented as standalone apps for a mobile device or tablet, as HTML5 apps running in a browser, or as any other type of app that can make a request to an HTTP endpoint and consume any response data. These apps might be developed and released by the same company that exposed the services, or by third-party app developers who make use of publicly available services.

The following image shows this type of model:

Because providers make their services available over the web, they must ensure that they have taken all necessary steps to secure and protect their services from unauthorized access. As a service provider, consider:

Security: How will you control access to your services to prevent unauthorized access?
Compatibility: Will your services work across different platforms and devices?
Measurability: How can you monitor your services to make sure they are available?

And many other considerations

After a client app has been released those accesses any services, the service provider is then required to make sure that those services continue to work overtime as they add, modify, or delete those services. The service provider must also have a way to keep app developers aware of any changes to the services to ensure that client apps stay in sync with those services.

Client app developers face challenges when trying to consume services from different providers. There are many technologies available today for use by a service provider to expose its services. The same client app might have to use one mechanism to consume a service from one provider, and a different mechanism to consume a service from a different provider. App developers can even face the situation where they have to use different mechanisms to consume services from the same provider.

Make services available through Apigee

Apigee enables you to provide secure access to your services with a well-defined API that is consistent across all of your services, regardless of service implementation. A consistent API:

Makes it easy for app developers to consume your services.
Enables you to change the backend service implementation without affecting the public API.
Enables you to take advantage of the analytics, developer portal, and other features built into Apigee.

The following image shows an architecture with Apigee handling the requests from client apps to your backend services:

Rather than having app developers consume your services directly, they access an API proxy created on Apigee. The API proxy functions as a mapping of a publicly available HTTP endpoint to your backend service. By creating an API proxy you let Apigee handle the security and authorization tasks required to protect your services, as well as to analyze and monitor those services.

Because app developers make HTTP requests to an API proxy, rather than directly to your services, developers do not need to know anything about the implementation of your services. All the developer needs to know is:

The URL of the API proxy endpoint.
Any query parameters, headers, or body parameters passed in a request.
Any required authentication and authorization credentials.
The format of the response, including the response data format, such as XML or JSON.

The API proxy isolates the app developer from your backend service. Therefore you are free to change the service implementation as long as the public API remains consistent. For example, you can change a database implementation, move your services to a new host, or make any other changes to the service implementation. By maintaining a consistent frontend API, existing client apps will continue to work regardless of changes on the backend.

You can use policies on the API proxy to add functionality to a service without having to make any changes to the backend service. For example, you can add policies to your proxy to perform data transformations and filtering, add security, execute conditional logic or custom code, and to perform many other actions. The important thing to remember is you implement policies on Apigee, not on your backend server.

Why do you need Apigee?

While exposing the APIs to the public, you may face challenges like:

Securing your APIs from OWASP threats.
Enforcing DDoS protection, and OAuth and JWT based access control.
Generating rate-plans and monetizing APIs.
Generating business use-case related analytics reports.
Global Reach and Performance
Privacy and Compliance

Apigee can perform these activities with minimal configuration. This drastically reduces the development effort required to make the APIs public ready.

The backend APIs are deployed in Google Cloud, Azure and AWS with each cloud deployment having a Load Balancer in front. Apigee can be placed in front of the Load Balancers. Apigee is connected to the backend APIs over the public internet. To ensure authentication, Mutual TLS is enabled between Apigee and the Load Balancers.

Comparison between Apigee products

Apigee Edge

· Apigee Edge is the public cloud, SaaS (Software as a Service) version of Apigee.

· Both the runtime and the management plane are in the cloud, and not under your control.

· No direct networking setup between Apigee cloud and your VPC (Virtual Private Cloud).

· All connections to Apigee, and Apigee to the backend services are over the public internet.

· Apigee Edge can reside in front of any cloud provider or on-prem service.

Apigee X

· Apigee X is the latest variant released by Google.

· Like Apigee Edge, in Apigee X, both the management plane and the runtime are managed by GCP (Google Cloud Platform).

· The Apigee runtime resides in your VPC Network, and a GCP HTTP(s) Load Balancer serves as the entry point into Apigee.

Apigee Hybrid

· In Apigee Hybrid you control the runtime in any cloud providers.

· Since Anthos GKE cluster can be deployed on multiple cloud providers, Apigee Hybrid can also be installed in different providers.

Instead of public internet, which is used by Apigee Edge, we can use Apigee X or Apigee Hybrid which reside in the same network as your services thus adding security and reducing latency.

Apigee architecture

The following illustration shows the lifecycle of an API proxy call as it moves through the provisioned Apigee system components:

· A client app calls an Apigee API proxy.

· The request lands on a global L7 external HTTPS load balancer (XLB). The XLB is configured with an external/public IP and a TLS certificate.

· The XLB sends the request to a virtual machine (VM). The VM serves as a bridge between your VPC and Google’s VPC (managed by Apigee).

· The VM sends the request to Apigee, which processes the API proxy request.

· Apigee sends the request to the backend service, and the response is sent back to the client.

To get a better overview of Apigee X Architecture : Click Here

Steps for Set up of Apigee X

1.Some of the prerequisite — Before setting up Apigee

Set up — Google Cloud billing account, create a new google cloud account and install gcloud cli and curl.

I have created a project named as Apigee

2.Then you add your project to your billing account. Go to billing → Manage Billing Accounts → Add your project to your billing account.

3.Enable these APIs in your Apigee project

$ export PROJECT_ID=YOUR_PROJECT_ID

$ gcloud services enable \
apigee.googleapis.com \
apigeeconnect.googleapis.com \
cloudresourcemanager.googleapis.com \
compute.googleapis.com \
container.googleapis.com \
pubsub.googleapis.com — project $PROJECT_ID

4. Go to the Apigee X Page → Search on Bar

This is the Apigee Dashboard

5.Set Up Apigee for your project — Choose Evaluation plan for Apigee free trial for 60 days or Pay as you go plan. For this demo we are going through Pay as you plan

6.Enable these APIs in your project for Apigee X → Apigee X , Cloud Key Management Service, Service Networking APIs

7.After enabling APIs, create an Apigee Organization. Remember that the project ID and org name are always the same.

To create a new organization in the Apigee provisioning wizard:

· If it is not currently open, open the Apigee provisioning wizard. The wizard returns to the next incomplete install task.

· In the wizard, click Edit next to Apigee organization:

· The Create an Apigee organization view displays:

From the Analytics hosting region drop-down list, select the physical location where you want your analytics data stored. For example: us-central1.

Under Runtime database encryption key make the following selections:

· Choose a Cloud KMS location. The dropdown menu lists two groupings of locations: multi-regional and dual-regional are grouped together, and regional locations are in another grouping. Note that if you select a regional location, we cannot offer an SLA higher than 99.9%.

· Next, choose a customer-managed encryption key. If a key already exists in the KMS location you selected, you can pick it.

Click Grant to grant the service account permission to encrypt/decrypt with the selected key and then create Organization.

8. Service Networking automates the private connectivity setup (using VPC Network Peering) between your network and Apigee.

Select your VPC network from the Authorized network drop-down list. If you have not created a network, select the default VPC, which is created for all Cloud projects.

In the Reserve peering ranges section, choose one of these options:

· Automatically allocate IP ranges: Choose this option if you want Apigee to manage the IP range for you. We create two ranges, one of length /22 and one of length /28.

9.Create a Apigee Runtime Instance — An instance, or runtime instance, is where your project and related services are stored; it provides the user-facing endpoint for your services.

Set up runtime region — select the region in which you want your instance hosted.

Specify how you want to allocate an IP range. Choose between these options:

· Automatic (Recommended) — Apigee selects an available CIDR range with a prefix size of /22. No further action on your part is required.

· Custom — In advanced use cases, you may need to specify exactly which IP range you want Apigee to use. You must specify a custom IP range, and it must have a prefix size of /22. The range must be available as part of a private connection between your project and Apigee

Under Disk encryption key, choose a customer-managed encryption key. If a key already exists, you can pick it.

This request can take 40 minutes or longer to complete because Apigee creates the new instance, installs the Apigee resources on it, and sets up load balancing.

10. Now you can create a new environment and attach it to a new environment group.

An environment group is a logical grouping of environments. You define your hostnames on an environment group rather than individual environments so that they can be shared. A service on the group called the ingress redirects requests to different environments within the group based on the hostnames assigned to the group.

· In the Environment group name field, specify a name for your environment group. For example, dev-group. You cannot change the name of an environment group once it has been created.

· In the Environment group hostname field, specify the hostname that routes requests into this group. For example: apigee.nanditadevops.cloud

· You can specify a single hostname only in this field.

· In the Environment name field, specify a name for your environment. For example, dev. You cannot change the name of an environment once it has been created.

· Click Create & attach to create the new environment and attach it to the new environment group.

11. In the last step you need to choose whether to expose your new cluster to external requests or to keep it private (and only allow requests from within the firewall).

No Internet Access — Your APIs will only be accessible from your internal network. Each of the regions will be using different internal IP Address. This IP address is the internal access point for all requests. You will send a request to this IP address from a machine that is also inside the VPC.

Enable Internet Access — An HTTPS Load Balancer will be assigned a static external IP address. The load balancer will point your selected domain to all regions. Apigee creates a managed instance group (MIG) containing multiple VMs to proxy traffic between the load balancer and the Apigee runtime.

Whole Set Up Process for Apigee

12.Copy the External IP address for the domain name and add it to the A record in Cloud DNS — Create an A record that points apigee.nanditadevops.cloud to 34.120.137.104

For creating zone in Cloud DNS — Enable Cloud DNS API

13.Create a zone with the below details — Make it public or private , put a zone-name as per your choice and add your domain name that you have purchased and click create

Add the nameserver records from Cloud DNS to your Go daddy account.

14. Create an A record that points apigee.nanditadevops.cloud to 34.120.137.104 in your Cloud DNS zone.

15. Created a Backend Server Nginx in one of compute engine.

Installed Nginx in Compute Engine

16. Added an A Record in Cloud DNS Zone with the External IP Address of the compute engine.

You can see how my domain is reflecting nginx page

Now let’s go to the Apigee X Dashboard

17.Create a Nginx API Proxy for Backend Server — Go to Develop → API Proxies → Select Reverse Proxy → Add name and add target path (domain) and base path.

The Proxy Base Path is part of the URL used to make requests to your API. Apigee uses the URL to match and route incoming requests to the proper API proxy.

Target (Existing API): This defines the target URL that Apigee invokes on a request to the API proxy. The service is hosted at Apigee and returns simple data. It requires no API key or access token.

18. After creating a new proxy, you must deploy it so that you can try it out. You can see that nginx-proxy is deployed with revision 1.

19.Add a step of Response Cache for your Nginx-Proxy — To see the variation of latency in the proxy

You can see the nginx page on apigee domain created during environment in Apigee

20. Go to Publish field and create API Products. Add name, description, display name and add environment which was created.

Attach the API Product to the Nginx Proxy

21. Creating Portal for the API Product — Add a name and description to it.

22. Choose API Catalog in the Nginx Portal created

23. Click on the + Symbol and add an API product to the catalog

24. See the API Portal Dashboard — Click on the Live Portal placed on top right-hand corner. (Check on the box — Published, add a title and description, add an image and Documentation source)