0:00
Hi. In the next few minutes,
I'll go over the technology stack used within the Apigee Edge platform,
which would provide a basic understanding of the architecture,
underlying components, and their functions.
Apigee Edge platform has three major capabilities services: API services,
analytic services, and the developer services.
Within these services, we have the gateway,
which mainly routes and processes the API,
UIs for the enterprise admin,
and the developer portals,
infrastructure services, which handles the persistence of runtime and analytics data,
and the management server that provides
APIs for all configurations and management activities.
Apigee Edge, as a platform, is horizontally scalable,
but additional gateway components can be added to keep up with increased API volume,
high availability, and other resiliency requirements.
As the number of gateway increases,
some of the supporting infrastructure services may need to scale out as highlighted.
For highly scaled infrastructure,
the components can also be set up in
a highly available manner within a single zone or across zones,
for example, across East and West regions.
Many of these components, as highlighted,
can scale out independently from each
other providing more flexibility and minimizing downtime.
For multi-datacenter and disaster recovery scale infrastructure,
the platform is capable of scaling across
multiple datacenters and regions in an active-active fashion.
It also allows active data application between sites using eventual consistency.
Each service has a mixture of
Apigee Stack and open source components that talks to each other,
performing a specific function.
Within the API services,
we have the router that handles
all incoming API traffic and dispatches it to the message processor.
Message processor executes all the policies
for a given specific organization and environment.
Management server provides APIs for all configurations and management tasks.
Enterprise UI offers an extended capability.
Cassandra stores application configurations,
API keys, and the OAuth tokens.
Zookeeper contains service configuration data.
OpenIdap contains the automization users and their roles.
Within the analytic services,
we have the Qpid server and the Qpid queuing system that transports
the analytics data and
the Postgres server and the PostgreSQL database to manage the analytics database.
And within developer services,
we have the developer portal and MySQL database,
mainly used to expose the API documentation,
register external developers and their apps.
Now that we understand what are the different components and the higher level functions,
let's talk about what happens when an API call is made and the request hits Apigee.
The routers receive the request and sends them to their message processors.
Message processor will then execute the policies within
the API proxy implementation and forward the request to the backend system.
Message processor interacts with Cassandra for token validation and other policies.
The message processor waits for the response from the backend system,
processes it, and then sends it back to the client via the router.
Similar to the API flow,
let's cover the analytics flow.
The data is generated by the message processor and is asynchronously sent to the Qpid.
Qpid server consumes the analytics raw data and writes it onto the PostgreSQL database.
Postgres Server aggregates the data,
writes it into the PostgreSQL master database,
which can be used to query and generate different reports.
For more information on this topic,
refer to the documentation in the reader description.
And if you have any questions,
please post them on our community. Thank you.
Google Cloud Training
