apigee insallation

 

Pre-Requisites

---

For the purpose of the course and the installation of the Apigee API Platform, the following hardware and software is required:

• 6 Cloud instances, virtual machines or physical services with 4 core and 4 GB RAM, 100 GB disk.
• All instances should contain recommended OS: https://docs.apigee.com/release/supported-software
• All instances should be on the same network zone and allow connectivity between them.
• Internet Browser and SSH client are required for the labs.

In order to proceed with the course, you will need the Apigee OPDK software and valid install key. If your organization already have a license key you should use it for this class, if you don't have one already, please send a license request to apigee-coursera-license@google.com. Please use your Coursera log in email address in the request. You will have to accept Apigee's terms and conditions before a license can be generated and the process may take a few days.

you will receive an overview of the Apigee platform. 

APIs is allow you to connect applications to resources hosted on your back end systems. 

These APIs are deployed, 

and managed by an API management platform. 

A typical enterprise offers multiple connected digital experiences to their customers. 

These experiences are powered by a diverse set of applications. 

Applications range from mobile apps 

to third party systems owned by partners or customers. 

These applications often come with 

different requirements such as different types of data representation, 

different security models, and others. 

Expectations around these connected experiences are driven by business oriented KPIs. 

These KPIs typically require agility, 

faster time to market, 

and tailored user experiences. 

On the other hand, we have back end systems. 

The SLAs of back end systems depend on high availability, 

change control, and configuration management. 

The gap between the expectations of connected digital experiences, 

and back end systems often creates friction which 

results in a slow pace of change and lack of agility in most organizations. 

This disconnect is often described as two speed IT. 

Apigee helps to bridge the gap. 

APIs is deployed on Apigee can be used to break 

dependencies between applications and back end systems. 

APIs represent products that need to be managed. 

Apigee provides both API runtime execution and API product management. 

Breaking dependencies between applications and back end systems through 

API management with Apigee allows for faster innovation, 

the creation of tailored user experiences, and greater agility. 

At the same time, Apigee provides the availability, 

scalability, and security that enterprises demand. 

As we work to understand the role of an API management platform, 

it is important to understand the types of interactions API facilitate, 

and the stakeholders of these interactions. 

The Digital Value Chain captures these ideas. 

We read the Digital Value Chain from left to right. 

Companies want to provide customers with connected user experiences. 

These connected experiences are powered by applications. 

Applications are built by developers. 

Developers require access to resources and 

data which are exposed by companies through APIs. 

API products are built and managed by API teams. 

API teams coordinate with back end systems to consume data while 

creating API that meet the expectations of end users, and application developers. 

The Digital Value Chain illustrates not only the interactions that API facilitate, 

but also the key actors. 

It represents a reminder of the capabilities that an API platform should provide. 

With that understanding, let's explore Apigee's core capabilities. 

At a high level, Apigee Edge has three core capabilities. 

API services provide features related to API management and runtime execution, 

building and deploying API proxies as well as the execution of flows 

and policies within those proxies falls under API services. 

Developer services provide a collection of features to enable 

the interaction between the people consuming the APIs and those producing APIs. 

Developer portal and monetization are key for API adoption. 

Apigee provides rich and flexible 

analytics capabilities that can help address questions by business users, 

developers, and operations teams. 

APIs are products, managing products requires a clear understanding of their performance, 

adoption, and overall behavior. 

Using Apigee Edge, you can create API proxies. 

A proxy is a collection of XML files and resources that 

allow you to describe the request and response flow of an API call. 

Policies represent the building blocks of API proxies. 

They can be attached to specific points on the request and response flow, 

allowing you to model the behavior of 

a given API call Apigee Edge offers policies related to traffic management, 

mediation, and security as well as extensions. 

The developer portal provides a communication channel. 

It is how the team producing APIs that can 

interact with the developers consuming those APIs. 

The developer portal allows you to publish API specifications and relevant documentation. 

The portal provides developer self-service for 

registering applications and subscribing to API products. 

It facilitates API key distribution, 

and exposes application specific analytics. 

Monetization is a flexible, 

easy to use solution to realize the value of your APIs. 

Monetization allows you to create different revenue models, 

manage billing, and process payments. 

Monetization integrates with your developer portal 

allowing you to offer and manage plans for your API products. 

Apigee's analytics allow you to capture and visualize 

contextual data related to API execution, 

interactions between APIs and back-end systems, 

developers and their apps, 

error rates, performance, and latency and customer reporting. 

Apigee Edge exposes all of its functionality through APIs. 

Those APIs can be used for development as well as operational tasks. 

For example, you can deploy APIs, 

create users, and run analytics reports using APIs. 

The management API is consumed by the Apigee Edge enterprise 

UI as well as the installation and upgrade processes. 

You can use the management API for offline development, 

CICD automation, and other operational activities. 

By now, you should have a high level understanding of 

Apigee's core capabilities and its place within the enterprise. 

Understanding each individual component 

is critical to your understanding of Apigee Edge for private cloud as a whole. 

In this lesson, we will focus on building that understanding. 

Over the next few minutes, 

we will be covering Apigee Edge capabilities, 

how each component fits into the platform, 

and details about the underlying technology stack. 

Apigee Edge has three core functional areas: API services, 

developer services, and analytic services. 

On the diagram, Apigee capabilities are shown in blue, 

open source capabilities are green, 

items in grey represent customer-specific infrastructure and API clients. 

Apigee capabilities such as Gateway and analytics, 

rely on underlying open source infrastructure 

to support the storage and replication of data. 

The Gateway sits on the critical path. 

Components included in this capability represent the runtime for APIs deployed on Apigee. 

Apigee Edge is horizontally scalable. 

For most scenarios, adding capacity to handle 

more API calls is as simple as adding additional Gateways. 

At some point, scaling the Gateway horizontally may require scaling 

the supporting infrastructure to handle 

the additional data being generated by the system. 

Components associated with other capabilities such as the UI, 

system management and the developer portal, 

only need to scale based on requirements associated with those capabilities. 

Horizontal scalability applies to capabilities within the region, 

as well as across regions. 

By design, Apigee Edge is active active. 

By that, we mean there is 

continuous eventually consistent data replication 

across data stores located in all regions. 

There are two regions in this diagram. 

API traffic is channeled to one or both regions based on customer preferences, 

that is usually handled by a global load balancer or DNS resolution. 

Regions are independent of each other. 

API calls and runtime execution have affinity with the region in which they arrive. 

Once an API call arrives at a gateway, 

it will stay in the region where the gateway is located. 

Take a moment to internalize the concepts discussed so far, 

as they are key to your understanding of the Apigee Edge architecture. 

As we discussed this diagram, 

think about the blue and green boxes as services or components. 

For now, we will focus on the components responsibilities. 

Later on, we will discuss the relationship as 

well as how to group them to form installation topologies. 

Let's start with the critical path. 

On this diagram, the critical path is represented by 

the horizontal line extending from the client to the backend system. 

The first component on the critical path is the router. 

The router is responsible for exposing 

virtual hosts and load balancing incoming requests. 

The message processor represents the runtime container for APIs executed on Apigee. 

API calls executing on 

the message processors may perform one or more calls to backend systems. 

All calls to backend systems on Apigee are originated by message processors. 

Some APIs generate runtime data that needs to be stored within Apigee. 

API policies such as API key validation, OAuth, 

key value map, and cache require 

access to a data store for the storage and retrieval of runtime data. 

The Apigee runtime data store is cassandra. 

Cassandra is part of the critical path because it is used by 

API policies to store data during runtime execution. 

The full critical path consists of the router, 

message processor, and cassandra services. 

As long as these components are up and running, 

others can be down or unreachable without affecting API runtime availability. 

API calls executed on the message processors generate analytics events. 

These events are asynchronously generated and consumed. 

The analytics pipeline is described on the bottom right part of the diagram. 

The first component in the analytics pipeline is apache Qpid. 

Qpid is a queue broker, 

queues are provisioned here to store analytics data. 

Qpid server is responsible for moving data from Qpid queues to postgreSQL. 

Analytics raw data on postgreSQL are eventually 

aggregated in batches by a service called postgres server. 

Aggregate data are used to power some Apigee Edge analytics reports. 

On the left of the diagram, 

we find the management components. 

At the center of the section is the management server. 

The management server exposes the management API. 

This API allows you to add users, 

deploy APIs, and perform many other actions. 

While performing these actions, 

the management server leverages cassandra, zookeeper, 

and openldap to read and store 

relevant data associated with runtime or configuration state. 

Zookeeper stores data related to the configuration of the system. 

The wiring information between 

components and configuration state are stored in zookeeper. 

Openldap stores information related to role-based access control users, 

roles, and permissions used for administrative access to Apigee are stored here. 

The Enterprise UI is the administrative UI used by API teams to develop and manage APIs. 

This UI consumes the management API to perform all actions. 

All features in the Enterprise UI are available through the management API. 

At the bottom of the diagram, 

we find the developer portal. 

This portal is a Drupal based application. 

Drupal uses postgreSQL to store data about user accounts, sessions, and modules. 

Take some time to review the component diagram in detail, 

your understanding of how Apigee Edge components function and relate to 

each other is key to your understanding and management of the platform. 

For more information on this topic, 

refer to our documentation

Apigee uses specific terms to describe key capabilities and concepts. 

There is also structure at 

the application level of the platform that should be understood. 

In this lesson, we will focus on building understanding of those topics. 

As we move through this lesson, 

keep in mind the responsibilities of components discussed in the technology stack lesson. 

Having a clear understanding of components responsibilities, 

and relating that understanding to 

the logical organizational structure described in this lesson, 

is key for your work with Apigee. 

Over the next few minutes, 

we will focus on introducing some key concepts and terms used by Apigee. 

APIs to allow you to provide access to resources. 

On the slide, we will illustrate an example of a customer API. 

An API implementation is called an API proxy. 

An API proxy allows you to describe the request and response flow for a given API. 

Policies are attached to these flows. 

A policy allows you to intercept the flow and inject specific functionality. 

Apigee Edge offers many out of the box and extension policies, 

these can be used in the request and response flows. 

Conceptually, the entry point for API calls to an API proxy, 

is represented by a virtual host. 

Virtual hosts are exposed on the router, 

and allow you to direct requests to specific API proxies. 

Often, an API may call a single back-end system. 

Apigee Edge allows you to abstract back-end system URLs, 

making it easy to move API proxies between environments without needing to modify code. 

Target servers are used for this. 

A target server allows you to describe a back-end resource, 

and associate this definition to a name used by API proxies. 

API proxies and API flows are subdivided into proxy endpoint and target endpoint, 

as well as pre-flow, 

conditional flow and post flow. 

Day to day operations work usually does not use these concepts, 

but it is important to understand that they exist because the operations team may, 

at some point in time, provide requirements to API engineers. 

Apigee Edge offers many policies. 

It is relevant for operations to know about some of these. 

Policies such as cache, 

key value map, concurrent rate limit, 

Spike arrest, message logging and statistics collector, 

may apply to some operational requirements. 

The policies are implemented by API engineers during API proxy development. 

Operations will act as a stakeholder for applicable requirements, 

and work with the API team for the implementation of specific capabilities. 

On Apigee Edge, most policies are provided out of the box, 

these policies are described in XML. 

Developers simply configure the behavior on the policies. 

Even though XML policies allow you to address a wide range of scenarios, 

sometimes there is a need to implement custom behavior. 

Apigee Edge provides extension policies that allow 

API engineers to write custom code in JavaScript, Java and Python. 

Most API proxies should contain mostly XML policies. 

It is a red flag if you encounter an API proxy that contains only code. 

Next, we will focus on describing key aspects of Apigee Edge organizational structure. 

In Apigee terminology, a planet is what 

most people will call their installed Apigee environment. 

A planet is a collection of resources across one or more regions, 

dedicated to Apigee Edge. 

This includes all of the hardware, 

virtual machines or cloud instances in a given Apigee installation. 

Planets are subdivided into regions, 

a region is typically represented by a data center or cloud region. 

Pods represent a logical grouping of components by function. 

We use pods to group components together for configuration and management. 

Apigee Edge uses three pods, 

gateway, central and analytics. 

An organization is a logical boundary. 

Organizations enforce logical data partitioning and security, 

organizations are key to Apigee Edge multi tendency concepts. 

An organization is a tenet, 

Apigee Edge is a multi-tenet system. 

This means you can create one or more organizations on the same physical infrastructure. 

Environments can be visualized as working spaces within a given organization. 

Typically, environments are mapped to an API SDLC. 

Most customers create environments named dev, 

QA and so on. 

The relationship between organizations and environments is one too many. 

Each organization can contain one or more environment. 

Apigee Edge analytics data is partitioned by organization and environment. 

Virtual hosts represent the entry point to an environment. 

The relationship between environment and virtual host is one too many, 

each environment can have one or more of virtual hosts. 

Putting it all together, a planet can be visualized as follows. 

On the diagram, we illustrate an Apigee planet with three regions. 

The planet contains two organizations, A and B. 

Each organization contains two environments, 

A1 and A2, and B1 and B2 respectively. 

Notice that organizations and environments expand across the planet in all regions. 

This is an important concept. 

The scope of organizations and environments allows you to execute 

actions in a single location and influence the behavior of APIs, 

the platform, and infrastructure components across multiple regions. 

For example, deploying an API to environment A1 in region three, 

will deploy the API to A1 in regions one and two as well. 

This allows you to manage a distributed infrastructure from a centralized point. 

As you decide how many organizations and environments to create, remember what they are. 

Both organizations and environments are 

logical boundaries which enforce data partitioning and security. 

Two organizations share nothing. 

APIs, API keys and other items within a given organization, 

are not visible from others. 

When deciding how many organizations and environments to create, 

always assume an outside-in position. 

Do not let your internal limitations, 

challenges or preferences, drive what your customers see and use. 

For most customers, one production organization and one production environment is ideal. 

Having two or more organizations in production, 

implies that API consumers looking to use organization A APIs and organization B APIs, 

will require two sets of API keys. 

If your objective is to provide a consistent company wide API offering, 

two or more organizations will not help. 

One will provide a better experience to API consumers. 

Given the logical nature of environments, 

an API deployment is no more than 

a logical association between an API revision and the specified environment. 

On Apigee Edge, APIs are owned by organizations. 

Deploying APIs to an environment within 

the same organization does not require code artifact movement. 

We will explore API deployment in detail, later on. 

This diagram illustrates the concepts of regions, 

pods and servers, and their relationships to each other. 

On Apigee Edge, it is possible to add and 

remove logical and physical capacity from the system. 

During installation, each server is registered with its corresponding pod. 

Associations between servers and pods are managed using UUIDs. 

During installation, a UUID is generated for each server. 

These UUIDs are later used to register the server to the pod. 

An API product bundles resources, 

such as API proxies, 

in order to provide a specific level of 

access and functionality for client app developers. 

And API product typically specifies a list of API proxies along with access limits, 

the API key approval method, 

and other configurations that should be in place for all of the bundle proxies. 

API products are a key part of API management. 

Elements such as quota, 

and other characteristics of the API behavior, 

are defined as part of API products. 

API products allow delegation of API management to API product owners. 

Changes to products can be implemented without 

the intervention of API engineers or operations. 

Apigee Edge provides finally, 

grand role based access control. 

Users, roles and permissions are created, and stored in LDAP. 

Management of users and roles can be done through UI and management API. 

During installation, a collection of default roles is created. 

You can also create custom roles, 

tailoring them to your specific security and management requirements. 

In this lesson, 

we are going to talk about Apigee installation planning. 

Putting time into the planning process is critical to 

success when performing your on-prem Apigee installation. 

The upfront investment pays for itself in time saved later in the installation process. 

Let's discuss the planning activities you will need to perform. 

Requirements analysis, installation topology design, 

organization design and capacity planning. 

The requirements analysis process provides 

a key input to the design of the installation topology. 

It drives many of the decisions you will make when determining 

how many hosts you will need and what their relationships will be. 

When analyzing your requirements, 

here are some important considerations. 

Is the planet intended for non-production or production use? 

How many regions comprise the planet? 

And how many can fail before peak API traffic is impacted? 

What are the average and peak loads you expect to experience? 

How large are your average request in response payloads? 

How complex do you expect your API proxies to be? 

How many hosts are you willing to lose in 

each region before a regional fail-over is necessary? 

How long do you need to retain detailed analytics data? 

And how many redundant management servers do you need? 

And do you need local management servers in some regions for performance reasons? 

Do you intend to use the developer portal? 

These questions can help you determine whether an architecture template is suitable for 

your environment or whether it is more 

appropriate to custom design your own installation topology. 

In the previous module, fundamentals, 

we discussed some common installation topologies that you 

can use as is or fine tuned to meet your needs. 

We learned that components can be added, 

removed or relocated to suit your performance and availability requirements. 

All of this can be done independently for 

various Apigee subsystems which include API traffic processing, 

system management, analytics and the developer portal. 

For some additional architecture templates, follow the links shown here. 

Keep in mind that for on-prem installation, 

you will likely need more than one Apigee planet to 

meet all of your non-production and production needs. 

In addition to supporting your non-production development needs, 

your full array of installed planets will need to support the needs of 

the operations team that needs to test 

changes and upgrades to both infrastructure and software. 

If development work requires access to 

a non-production planet with production like uptime guarantees, 

you may need a separate dedicated Apigee planet 

exclusively for infrastructure operations use. 

Another important consideration in your installation topology is network zoning. 

A common requirement driven by security or regulatory rules is to split 

your installation across one or more networks which are separated by network firewalls. 

As shown here, Apigee uses many TCP ports for internal and external communication. 

Increasing the number of network zones and your architecture, 

for instance a DMZ zone, 

an App zone and a database zone, 

will increase the complexity of 

the network firewall configuration required to support that architecture. 

There are additional ports needed in a multi-region architecture. 

Follow the link shown here to learn more. 

Try to minimize the number of network zones to 

keep installation and support of the system straight forward. 

It's ideal to pass requests through the DMZ 

directly using your load balance infrastructure 

rather than placing routers and message processors in 

a network zone separate from the other Apigee hosts. 

Once you have decided on an installation topology, 

you will need to determine the correct Apigee organization 

and environment configuration for that architecture. 

Recall from the fundamentals course that organizations 

allow you to create security boundaries between system users, 

and environments allow you to group and configure deployable resources. 

In addition, physical message processor capacity for 

handling API requests is allocated at the environment level. 

By default, all message processor capacity is shared across all environments. 

But you may wish to allocate dedicated capacity to 

one or more environments for security or performance reasons. 

A common mapping for on prime installations is to 

create a single organization named after your company, 

with environments used to represent various stages in your SDLC such as dev, 

test, QA, staging and production. 

The organization name stays constant across 

non-production and production planets and 

the environments are split across those planets as appropriate. 

Analyzing your requirements and determining 

your initial installation topology is 

the first step to successfully serving your API platform users. 

But you also need to think about the growth of your API program over time. 

Capacity planning should be an ongoing process 

and it starts before your initial installation takes place. 

Take care to build your installation topology in a flexible way which 

allows you to add additional processing capacity and redundancy as needed. 

Diligently track your infrastructure resource usage, 

as well as, your API traffic rate and size projections. 

Without those data you can become a victim of your own success, 

when your API programs suddenly draws 

unexpected traffic which impacts the platform's overall quality of service. 

We'll discuss capacity planning thoroughly in a later course. 

For more on this topic, refer to our documentation. 

If you have any questions, 

please post them to our community. Thanks for watching.