WSO2 API Microgateway for Easier Development and Greater Scalability

WSO2 API Microgateway - 3.0
Rajith Roshan
Associate Technical Lead, WSO2 Inc.
Praminda Jayawardene
Senior Software Engineer, WSO2 Inc.

API Microgateway
Proxy that stands in front of microservices
Enables developers and operators with common control panel

WSO2
API Microgateway
Architecture
Components
● Gateway runtime
● Toolkit

● Command line interface(CLI) to manage microgateway projects
● Initialize microgateway projects with open API deﬁnitions
● Builds the projects to create
○ Runtime artifacts(APIs packed in) for runtime containers and
distributions
○ Immutable containers with APIs built in
○ Kubernetes artifacts used to deploy in k8s clusters
● Import APIs from WSO2 API Manager
● Download from : https://wso2.com/api-management/api-microgateway/
Toolkit

● Serves the requests applying
○ Security
○ Rate limiting
○ Transformations
○ Analytics and etc
● Available as archived distributions as well as docker images[1]
● Can be build burning APIs into container images to spawn immutable
containers
● Runs on top of artifacts generated by the toolkit
[1]- https://hub.docker.com/r/wso2/wso2micro-gw
Runtime

WSO2 API Microgateway for Easier Development and Greater Scalability

● Cloud native
● Developer centric
● Decentralized
● Designed for microservices
● Immutable
● Scalable
Components
● Gateway runtime
● Toolkit
WSO2
API Microgateway

● Comes as lightweight containers
○ Fast boot up times (< 1s)
○ Low memory footprint(256mb)
○ Low distribution size (~ 100 MB)
● Designed in a stateless manner
● Isolated from underlying system/OS
● Can be deployed on self-service, elastic and cloud infrastructure
● Agile DevOps and CI/CD
● Automated capabilities for deployment
● Developed with frameworks suited for cloud
1. Cloud Native

● Developer start creating microservices
● Define the open API definition for the microservices
● Initiates microgateway project from open API definition
● Build the microgateway project
● Locally test the service exposed via microgateway
2. Developer Centric

● Per API gateway
● Private jet and sidecar gateways
● Gateway for subset of APIs only
3. Decentralized

● Rebuild and redeploy using rolling updates, if API changes, new resource
get added
● Add a new gateway for new API
● Open API deﬁnitions should be ﬁnalized, prior deploying
● Immutable containers
● Immutable runtime artifacts for non containerized runtimes
4. Immutable

● Serves trafﬁc independently
○ Acts without key manager with self contained tokens
○ Local rate limiting capabilities
○ Stores analytics data
● Independently scale without having to scale other component
● Can be scaled with microservices when used as private jet or side car
mode
● Inbuilt support for container orchestration tools to manage scaling
5. Scalable

Use Case
● In microservices world certain functionality is provided by set of microservices developed by a team
● Developers needs to document the services(Interfaces) as APIs to be used by outside world
● Developer team maintains a open API definitions for microservices
● Developer team needs to test the microservices with security and etc exposed via gateways
1. Based on Open API Definition
Application
● Extend the API definition with microgateway specific
vendor extensions.
● Create microgateway project using API definition and
creates runtime artifacts locally
● Test the functionality using microgateway runtime by
providing the runtime artifacts.

Use Case
● Set of microservices for a single business use case (for ex: online book store)
● Each microservice with different endpoints
● Defines a single open API definition for all the microservices
● Expose the microservices as APIs via the API gateway
Application
● Extend the API definition with microgateway specific vendor extensions to add per resource endpoints.
paths:
"/books/list":
get:
summary: Get the list of books
x-wso2-production-endpoints:
urls:
- http://35.226.63.174:30941
"/books/search/{query}":
get:
x-wso2-production-endpoints:
urls:
- http://35.226.63.174:31891
2. Per resource endpoints

Use Case
● Certain organizations provide services for trusted partners only (for ex: banks)
● In order to access services initial agreement required to build the trust
● Organization and clients enforces trust by sharing the certiﬁcates with each other.
Application
● Enable mutual ssl in microgateway for APIs
● Share the public certiﬁcates of microgateway and clients with each other.
3. Mutual SSL Authentication

Use Case
● Certain clients might send invalid requests or bogus requests to manipulate server
data
● Services need a way to validate the clients request is valid with the service schema
Application
● Microgateway intercepts the request/response and validates it against the open API
scheme
● Validates the request/response body
4. Request/Response Schema Validation

Use Case
● In microservices architecture services may be dynamic
● Services might have dynamically assigned IP, ports every time they respawn.
● Central(key/value store) place maintains the dynamically assigned IPs for services
Application
● Conﬁgure ETCD to maintain the services dynamic endpoints
● Connect microgateway with ETCD server to periodically pulls updated data
● Microgateway dynamically routes trafﬁc to the correct endpoint address
5. Service Discovery with ETCD

5. Service Discovery with ETCD

Use Case
● Services might limit the number of requests that comes within a unit time period.
● This limitation is may be due to protect services from overloading due to
infrastructure limitations
● Protect APIs from security attacks like Denial of Service(DoS)
Application
● Conﬁgure microgateway with WSO2 Trafﬁc manager
● Apply global throttle counters for the cluster of microgateways
6. Global Throttling

Use Case
● Services would require requests to be enriched with certain data which are not accessible to
clients
● Server responses should be transformed in a way that all clients can understand them
● This would require intercepting request and responses and modifying them
Application
● Write ballerina functions for transformations and plug those into the services
● Functions can be defined as open API extensions in the definition file
paths:
"/pet/findByStatus":
get:
summary: Finds Pets by status
description: Multiple status values can be provided with comma separated strings
operationId: findPetsByStatus
x-wso2-request-interceptor: validateRequest
x-wso2-response-interceptor: validateResponse
7. On the Fly Transformations

● Microgateway expose http2 services to clients
● Does http 1.1 to http 2 transformations and vice versa
● Expose http 1.1 services as http2 for clients
User story 1 - Both client and backend supports HTTP 2.0
8. HTTP2 Support

User story 2 - The client supports HTTP 2.0 but the backend does not support HTTP 2.0
User Story 3 - The client does not support HTTP/2 but the backend supports HTTP 2.0
8. HTTP2 Support

● JWT will be validated using the signature
● If the signature is valid, revoked tokens will also be validated as true until token get
expired
● If the JWT is revoked microgateway should be notified of revoked jwt tokens
Supported Notification types
1. Persistent notification via an ETCD server
- Microgateway connects to ETCD server during startup and fetch all the revoked tokens and
stores in the memory
2. Real Time notification via an JMS subscription
- Microgateway subscribes to an configurable jms topic and get real time notifications regarding
revoked tokens
9. JWT Revocation

Upcoming Tutorials
● Deploy in k8s with cluster of gateways
● Service discovery with etcd
● Apply security (OAuth2, Mutual ssl, JWT,basic auth)
● Application of microgateway in microservices architecture
● Microgateway schema validation
● On the ﬂy transformations with interceptors
● Microgateway local and distributed throttling
● JWT Revocation
Will be updated via the WSO2 blog :
https://wso2.com/blogs/thesource/2019/07/wso2-api-microgateway-3-0-is-released/

Development and Operational
Process

● Developer start creating microservice
● Define the open API definition for the microservice
● Initiates microgateway project from open API definition
● Build the microgateway project
● Locally test the service exposed via microgateway
● Commits the project to source version system (ex :Git)
1. Development Cycle

● Developers collectively develop other microservices
● Checkout the microgateway project
● Modify the project to add the newly added microservices
● Build the microgateway project with multiple services now
● Locally test the speciﬁc microservice via gateway
● Individually each developer commits changes to the project
1. Development Cycle (Contd)

● Individual microservices are included in the microgateway project
● Request comes to deploy in the development environment
● Operations team checkouts the project
● Creates the deployment conﬁguration for the project
● Build the project with deployment conﬁguration
● Deploy the microgateways using the build artifacts (In Docker/k8s)
2. Operations Process

● Completes the deployment and testing of dev environment
● Creates the deployment configuration file for the test environment
● Configuration is changed to use the same runtime artifacts(executables/ containers)
from dev environment
● Provides environment specific data as environment variables
● Build the project with deployment configuration for test
● Deploy the microgateways using the build artifacts (In Docker/k8s)
● Continue process until deployed in production
3. CI/CD Process

1. Monolithic Centralized Deployments

2. Private Jet or Sidecar in MSA

3. Expose Microservices as APIs in a Service
Mesh

WSO2 API Microgateway for Easier Development and Greater Scalability

Recommended

More Related Content

What's hot (20)

Similar to WSO2 API Microgateway for Easier Development and Greater Scalability (20)

More from WSO2 (20)

Recently uploaded (20)

WSO2 API Microgateway for Easier Development and Greater Scalability