This document discusses the WSO2 API Microgateway, including its architecture, components, and deployment patterns. The microgateway is a lightweight proxy that enables common control and management of microservices. It consists of a gateway runtime and toolkit. The toolkit allows developers to initialize projects from OpenAPI definitions, build runtime artifacts, and deploy to containers and Kubernetes. The runtime serves requests by applying security, transformations, and analytics. It is lightweight, stateless, and scalable.

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

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

3. Architecture

4. WSO2
API Microgateway
Architecture
Components
● Gateway runtime
● Toolkit

5. ● Command line interface(CLI) to manage microgateway projects
● Initialize microgateway projects with open API definitions
● 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

6. ● 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

7. Demo

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

10. ● 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

11. ● 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

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

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

14. ● Serves traffic 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

15. New Features

16. 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.

17. 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

18. 2. Per Resource Endpoints

19. 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 certificates with each other.
Application
● Enable mutual ssl in microgateway for APIs
● Share the public certificates of microgateway and clients with each other.
3. Mutual SSL Authentication

20. 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

21. 4. Request Schema Validation

22. 4. Response Schema Validation

23. 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
● Configure ETCD to maintain the services dynamic endpoints
● Connect microgateway with ETCD server to periodically pulls updated data
● Microgateway dynamically routes traffic to the correct endpoint address
5. Service Discovery with ETCD

24. 5. Service Discovery with ETCD

25. 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
● Configure microgateway with WSO2 Traffic manager
● Apply global throttle counters for the cluster of microgateways
6. Global Throttling

26. 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

27. 7. On the Fly Transformations

28. ● 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

29. 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

30. ● 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

31. 9. JWT Revocation

32. 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 fly 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/

33. Development and Operational
Process

34. ● 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

35. ● 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 specific microservice via gateway
● Individually each developer commits changes to the project
1. Development Cycle (Contd)

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

38. ● 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

40. Demo

41. Deployment Patterns

42. 1. Monolithic Centralized Deployments

43. 2. Private Jet or Sidecar in MSA

44. 3. Expose Microservices as APIs in a Service
Mesh

45. THANK YOU
wso2.com