About the webinar The use of an API gateway and the move to microservices are two of the most important trends in application development. But are they similar, or different; complementary, or contradictory? In this webinar, we discuss the advantages of an API gateway, the advantages of microservices development, and how and when they can work together. The NGINX Microservices Reference Architecture (MRA) uses three different network architectures, with service mesh as a fourth. We describe how an API gateway relates to each of these network architectures and how to reduce rework if your application needs to evolve from one architecture to another. Speakers: Charles Pretzer, Technical Architect, NGINX, Inc. Floyd Smith, Director of Content Marketing, NGINX, Inc.

2. MRA AMA Part 11
API Gateway and the NGINX Microservices
Reference Architecture
Speakers:
Charles Pretzer
Floyd Smith

3. Who are we?
3
Charles Pretzer
Technical Architect
Formerly:
• Software Architect Consultant
• Engineering Lead at Zinio, StyleHive,
and others
Floyd Smith
Director, Content Marketing
Formerly:
• Apple, Alta Vista, Google, startups
• Author of multiple books on technology,
including web, marketing, usability

4. Agenda
1. Introducing NGINX
2. Application Programming Interfaces
3. NGINX Microservices Network Architectures
4. NGINX Microservices Reference Architecture
5. API Gateway
6. MRA with an API Gateway
○ Proxy Model
○ Router Mesh
○ Fabric Model
7. Q&A

5. Introducing NGINX

6. Introducing NGINX
6
• NGINX OSS released 2003
• NGINX Plus first released in 2013
• NGINX, Inc. is VC-backed by leading investors in
enterprise software
• Offices in SF, Sunnyvale, Singapore, Cork,
Cambridge, & Moscow
• 1,500+ commercial customers
• 200+ employees

7. >50%of the top 100,000 busiest websites
Source: W3Techs Web Technology Survey

8. Where NGINX Plus fits

9. NGINX Plus works in all environments

10. NGINX Microservices roadmap
• Start with Gus Robertson keynote at nginx.conf 2017
• See Owen Garrett’s Roadmap presentation….
• …and Chris and Rachael’s Controller demo
• Also, Chris Richardson series, Intro to Microservices…
• …and Chris Stetson series, NGINX MRA
• …and much more; contact Sales for free evaluation

11. Application Programming
Interfaces

12. openapi: “3.0.0”
info:
title: API Example
version: v1
paths:
/:
get:
operationId: getExample
…
/submit-form:
post:
operationId: postExample
...
What is an Application Programming Interface?
● In this context we are
talking about Web APIs
● Logic which provides one
or more entry points
which are generally
accessed over a network
protocol
Logic
https://github.com/OAI/OpenAPI-Specification/blob/master/examples/v3.0/api-with-examples.yaml

13. openapi: “3.0.0”
info:
title: API Example
version: v1
paths:
/:
get:
operationId: getExample
…
/submit-form:
post:
operationId: postExample
...
cURL examples: GET
$ curl -X GET https://api-example.nginx.com
…
> GET /status HTTP/2
> Host: api-example.nginx.com
> User-Agent: curl/7.54.0
> Accept: */*
>
* Connection state changed
(MAX_CONCURRENT_STREAMS updated)!
< HTTP/2 200
< server: nginx
< date: Wed, 11 Jul 2018 06:05:36 GMT
< content-type: application/json
< expires: Thu, 01 Jan 1970 00:00:01 GMT
< cache-control: no-cache
...
Logic

14. openapi: “3.0.0”
info:
title: API Example
version: v1
paths:
/:
get:
operationId: getExample
…
/submit-form:
post:
operationId: postExample
...
cURL examples: POST
$ curl -X POST https://api-example.nginx.com -
d “param1=apple&param2=banana”
…
> POST /status HTTP/2
> Host: api-example.nginx.com
> User-Agent: curl/7.54.0
> Accept: */*
>
* Connection state changed
(MAX_CONCURRENT_STREAMS updated)!
< HTTP/2 200
< server: nginx
< date: Wed, 11 Jul 2018 06:05:36 GMT
< content-type: application/json
< expires: Thu, 01 Jan 1970 00:00:01 GMT
< cache-control: no-cache
...
Logic
Any valid verb can be used: GET, POST, PUT, PATCH,
DELETE
- https://www.restapitutorial.com/lessons/httpmethods.html

15. NGINX Microservices
Architectures

16. Proxy Model
● Load Balances requests
to services
● Analogous to connectivity
for a horizontally scaled
monolith
● Services are left to
communicate with each
other
● Acts as an entry point for
monolith migration
● Lays the foundation for
building a service mesh

17. Router Mesh
● Standalone NGINX Plus
instance which acts as a
traffic manager
● Provides service
discovery via DNS SRV
records
● Load balances to
instances of services
● NGINX Plus provides
active health checks
allowing for circuit
breaker functionality

18. Fabric Model
● NGINX Plus exists as a
sidecar within the same
container as the service
● NGINX Plus and the app
communicate only on
localhost
● Instances of NGINX Plus
communicate directly
with each other
● Incorporates all the
features of the Router
Mesh and adds
persistent SSL
connections

19. Persistent SSL Connections
● An SSL handshake requires as
few as seven steps or as many
as 10
● NGINX Plus uses a keepalive
mechanism to persist
connections between instances
● The number of handshakes is
greatly reduced, thereby
decreasing overall latency
while maintaining encrypted
transmission

20. NGINX Microservices
Reference Architecture

21. Ingenious
● Seven distinct services written in
different languages comprising a
single application
● Release 1 uses the Fabric Model
○ Router Mesh will be implemented in a
future release
● Quick Start:
○ https://github.com/nginxinc/mra-ingenious

22. API Gateway

23. Life without an API Gateway
● Requires that subdomains be
configured for each resource
● Very brittle
○ Names of endpoints/subdomains
cannot change dynamically and are
subject to DNS (time to live) TTL
○ Configuration management is complex
○ Security is implemented on a per-
domain basis
A
B
C
endpoint-a.example.com
endpoint-b.example.com
endpoint-c.example.com

24. Life with an API Gateway
● Single domain for entrypoint
○ api.example.com
○ single set of SSL certs to manage
● Path based routing
A
B
C
api.example.com/endpoint-a
api.example.com/endpoint-c
API
Gateway
api.example.com/endpoint-b

25. API Gateway
● Routes requests to endpoint
providers

26. MRA with an API Gateway

27. Ingenious
● The auth-proxy service is the
single entry point into the system
● Each of the services communicate
directly with each other instead of
through a centralized routing
mechanism like an API Gateway

28. Ingenious
● MRA with an API
Gateway
● Each service is exposed
on the network in such a
way that the NGINX API
Gateway can route traffic
to it
auth-proxy
album
manager
content
service
mra-api.example.com/
/content-service
API
Gateway
/album-manager
pages
/pages
resizer
/resizer
uploader
/uploader
user
manager
/user-manager

29. Proxy Model

30. Proxy Model
● Load Balances requests
to services
● Analogous to connectivity
for a horizontally scaled
monolith
● Services are left to
communicate with each
other
● Acts as an entry point for
monolith migration
● Lays the foundation for
building a service mesh

31. Ingenious
● Not much different!
● Simply put, the location
based routing of NGINX
provides API Gateway
functionality
● In this example, the
services can
communicate directly with
each other, or through
the API Gateway
auth-proxy
album
manager
content
service
mra-api.example.com/
/content-service
API
Gateway
/album-manager
pages
/pages
resizer
/resizer
uploader
/uploader
user
manager
/user-manager

32. Router Mesh

33. Router Mesh
● Standalone NGINX Plus
instance which acts as a
traffic manager
● Provides service
discovery via DNS SRV
records
● Load balances to
instances of services
● NGINX Plus provides
active health checks
allowing for circuit
breaker functionality

34. Ingenious
● The Router Mesh is effectively an
API Gateway
● The configuration has the paths of
each of the services and traffic is
routed from the Load
Balancer/Web Application Firewall
● All services communicate with
each other through the Router
Mesh
auth-proxy
album
manager
content
service
mra-api.example.com/
/content-service
Router
Mesh
/album-manager
pages
/pages
resizer
/resizer
uploader
/uploader
user
manager
/user-manager
LB/WAF

35. Fabric Model

36. Fabric Model
● NGINX Plus exists as a
sidecar within the same
container as the service
● NGINX Plus and the app
communicate only on
localhost
● Instances of NGINX Plus
communicate directly
with each other
● Incorporates all the
features of the Router
Mesh and adds
persistent SSL
connections

37. Ingenious
● Similar to Proxy Model
configuration
● Added benefit of
persistent TLS/SSL
connections
● Services can
communicate directly with
each other or through the
API Gateway
auth-proxy
album
manager
content
service
mra-api.example.com/
/content-service
API
Gateway
/album-manager
pages
/pages
user
manager
/user-manager
resizer
/resizer
uploader
/uploader

38. Persistent SSL Connections
● An SSL handshake requires as
few as seven steps or as many
as 10
● NGINX Plus uses a keepalive
mechanism to persist
connections between instances
● The number of handshakes is
greatly reduced, thereby
decreasing overall latency
while maintaining encrypted
transmission

39. Q & A

40. Thank You