What is Environment?

Environment Concept

Environment corresponds to the Namespace concept in Kubernetes. Kubernetes clusters can manage large amounts of disconnected workloads simultaneously. Kubernetes uses a concept called Namespace to reduce the complexity of objects within the cluster.

bilgi

Namespaces allow objects to be grouped together and these groups to be filtered and controlled as a unit. This enables purposes such as applying customized access control policies or separating all units from each other for a test environment.

Environment Features

Isolation

Each environment is completely isolated from other environments. API Proxies in one environment cannot directly communicate with API Proxies in other environments.

Resource Allocation

Each environment has dedicated resources such as CPU and RAM. These resources are not shared with other environments.

Access Address

Each environment has its own access address (URL). API Proxies in the environment can be accessed through this address.

Settings

Each environment has its own specific settings. These settings are independent of other environments.

Environment Structure

The following diagram shows what an environment contains at a high level:

flowchart TD
    Environment[🌍 Environment<br/>Kubernetes Namespace]
    
    Environment --> Service[Service<br/>NodePort<br/>Access Layer]
    Environment --> WorkerPods[Worker Pods<br/>Gateway Engine<br/>API Proxy Execution]
    Environment --> CachePods[Cache Pods<br/>Cache Management]
    Environment --> IntegrationPods[Integration Pods<br/>API Integrator Tasks]
    Environment --> APITrafficLog[API Traffic Log Connectors<br/>Logging Connections]
    Environment --> AccessURL[Access URL<br/>Access Address]
    
    WorkerPods --> APIProxies[API Proxies<br/>Deployed APIs]
    
    style Environment fill:#e3f2fd,stroke:#1976d2,stroke-width:3px
    style Service fill:#fff3e0,stroke:#f57c00,stroke-width:2px
    style WorkerPods fill:#e8f5e9,stroke:#388e3c,stroke-width:2px
    style CachePods fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px
    style IntegrationPods fill:#fce4ec,stroke:#c2185b,stroke-width:2px
    style APITrafficLog fill:#fff9c4,stroke:#f9a825,stroke-width:2px
    style AccessURL fill:#f5f5f5,stroke:#616161,stroke-width:2px
    style APIProxies fill:#e1f5ff,stroke:#0277bd,stroke-width:2px

Why Use Multiple Environments?

It is recommended to use multiple environments for two main reasons:

1. Lifecycle Management

Managing the API lifecycle by creating environments for different purposes such as Development, Test, Sandbox, and Production.

Development

Development environment. The environment where new features are developed and tested.

Test

Test environment. The environment where comprehensive tests of developed features are performed. Also used to measure the adequacy of hardware resources.

Sandbox

Sandbox environment. Used to simulate real users before the product is finished and released to end users. Provides the ability to perform safe testing without affecting the production process and close to the production process.

Production

Production environment. The environment where the live system runs. Designed for end-user use and configured to handle client load.

uyarı

Important Differences:

• Difference between test environment and sandbox environment: The product (API Proxy or Application) is enabled on test environment to test during development, and on sandbox environment to simulate real users before the product is finished and released to end users.
• Installation is performed on the relevant role environment according to the usage purpose of the API Proxy. The same API Proxy can be enabled on different environments for different purposes.
• Each environment operates independently of the others.

2. Resource Isolation

Grouping resource-intensive APIs to run in isolation, thus preventing other APIs' performance from being adversely affected.

bilgi

For example, high-traffic APIs can run in one environment, while low-traffic APIs can run in another environment. This optimizes resource usage.

Environment Components

An environment contains the following components:

Namespace

The environment concept in the Apinizer Platform corresponds to the Namespace concept in Kubernetes. Each environment is created as a Namespace in Kubernetes.

Worker Pods (Gateway Engine)

Pods where API Proxies run. It is the core module of the Apinizer Platform, responsible for routing all API requests to Backend APIs and operates as a Policy Enforcement Point.

Cache Pods

Distributed cache pods. The environment where cache values required in Apinizer are stored.

Integration Pods

Pods where API Integrator tasks run. Manages integration operations.

Service

Environment Service is created to access the Apinizer Worker pod in the Environment Deployment. The service is the layer that handles requests coming to all pods. It is located in front of the pods. NodePort is used by default, and other service types are not supported by Apinizer.

API Traffic Log Connectors

Connectors that provide connection to log servers (e.g., Elasticsearch cluster) where all API Traffic and requests in the created environment will be logged.

Access URL (Access Address)

Access URL is the external access address of the Proxy. It is specified as https://<your-IP-address>. Messages can be sent to Proxies using the external access address information.

Environment Types and Protocols

Environment Types

When creating an environment, either Test or Production type is selected. This type is important in terms of license management and resource allocation.

Communication Protocol Types

When creating an environment, one of the following communication protocols can be selected:

• HTTP: Standard HTTP protocol
• gRPC: High-performance RPC protocol
• HTTP+WebSocket: Combined use of HTTP and WebSocket protocols

Environment Access Address

An API Proxy can be accessed through the access address of the environment where it is deployed.

Access Address Structure

An API Proxy's access address is as follows:

http://demo.apinizer.com/apigateway/myproxy

Component	Description
http://demo.apinizer.com/	Environment Access Address
apigateway/	Root Context
myproxy	API Proxy Relative Path

Access Address Configuration

The access address to be defined for the environment is usually a DNS address defined in a load balancer such as WAF or Nginx. Environments defined in Apinizer correspond to a namespace in Kubernetes. A Kubernetes service of NodePort type is automatically created by Apinizer to access Apinizer Workers running within the namespace.

Environment Management

Creating an Environment

When creating a new environment, the following information is defined:

• Type: Test or Production
• Communication Protocol Type: HTTP, gRPC, or HTTP+WebSocket
• Environment Name: Unique name identifying the environment (corresponds to namespace in Kubernetes)
• Key: A shortened key specific to the environment
• Node List: Which Kubernetes servers the environment will run on
• Project: Projects where the environment can be used (if left empty, it can be used in all projects)
• Access URL Address: External access address of API Proxies running in the environment
• Gateway Server Access URL: NodePort or ingress type service access address required for configurations made in the Apinizer Management Console to be loaded into Gateway Pods
• Resource Limits: CPU and RAM limits
• Settings: Configuration specific to the environment
• Description: Can be used for management convenience and important notes

bilgi

For detailed environment creation and management, you can refer to the Gateway Runtimes page.

API Proxy Deployment

API Proxies can be deployed to one or more environments. The same API Proxy can run with different versions in different environments.

uyarı

Important Notes:

• For a client to access an API Proxy, it must be deployed to at least one environment.
• All environments where installation is performed are located within a cluster and run on servers where the Apinizer Platform is installed.

Project and Environment Relationship

Projects and environments are different concepts:

• Project: Logical organization unit (which APIs work together?)
• Environment: Physical/resource unit (where do APIs run?)

API Proxies in a project can be deployed to different environments:

Project: E-Commerce APIs
├─ Development Environment
│  ├─ Product API v1.0
│  └─ Order API v1.0
├─ Test Environment
│  ├─ Product API v1.1
│  └─ Order API v1.1
├─ Sandbox Environment
│  ├─ Product API v1.2
│  └─ Order API v1.2
└─ Production Environment
   ├─ Product API v1.2
   └─ Order API v1.2

When creating an environment, it can be determined which projects the environment can be used in. If the project selection is left empty, the environment can be used in all projects.

Environment and Kubernetes Namespace Relationship

All environments created with the Apinizer Platform run on Kubernetes infrastructure. Each environment corresponds to a Namespace in Kubernetes:

Apinizer Environment → Kubernetes Namespace
├─ Development → apinizer-dev
├─ Test → apinizer-test
├─ Sandbox → apinizer-sandbox
└─ Production → apinizer-prod

This structure enables:

• Isolation between environments
• Resource usage control
• Access control
• Scalability management

Next Steps

What is Project?

Learn about the project concept

What is API Proxy?

Learn about the API Proxy concept

Gateway Runtimes

Environment creation and management

Deployment Models

Review deployment models