Upload
benjamin-scholler
View
55
Download
0
Embed Size (px)
Citation preview
Nginx Conference 2016Learnings and State of the Industry
SEPTEMBER 12, 2016BEN SCHOLLER
Great conference to see the state of the industry!
● Nginx’s role doing more than serving HTTP○ Modules providing more and more functionality○ Authentication in C!
○ Creating frameworks for other software: Kong, Virtuozzo○ Nginx Plus & Amplify
● APIs are more important than ever○ Businesses living and dying by how their public APIs are built,
documented and utilized.○ Hypermedia gaining a little traction (HATEOAS)○ Gateway functionality handling auth, logging, A/B testing, rate limiting,
transformations, circuit breaker, the list goes on!
Brief Summary
● Heavy leaning on microservices○ Completely contained services that represent core business functionality○ Scalable to meet demand○ Easily upgraded or swapped out - Just keep the interface the same
● Serverless is seen as the next wave○ Completely granular functionality
○ Event driven
○ Huge emphasis on efficiency - code golf
○ AWS Lambda, Azure Functions, Google Functions, etc
Brief Summary
Nginx
Nginx● Modules further extending Nginx than initial implementation. MySQL, Redis,
AWS, Akamai, GridFS, Java, etc. Written in C for speed.
● Treated more and more as a low level API gateway, common to use as front for microservice for fast response times, TCP/UDP flow
● Nginx Plus offering more - Load balancing, proprietary monitoring, upstream configuration, VRRP for HA, cookie persistence
● Nginx Amplify for visual monitoring - Similar to Appd, provides dashboard for servers with Nginx running, recommendations on configuration, can set up thresholds and alerting. Like a mix of Appd and Kibana.
Analysis of Learnings
Gateways are abstracting overhead of API management:● Moving meta functions of an API to proxy in front simplifies logic and lifts load● Most gateways allow you to make requests to multiple endpoints and
transform the data into one response○ Ex: /car on Gateway, which calls /car/tire, /car/engine, /car/transmission
and compiles to one response● Logging and rate limiting can be handled by gateway● Authentication at gateway - Token validation and response is the same across
all endpoints, less complexity in functions● Circuit breaker - If a service goes down, the API Gateway can handle the error
gracefully to let clients know there is an issue with retrieving data
APIs
Based on endpoint, you can route to a specific microservice with an API Gateway. This helps better scale your system to meet functional demands.
In this example, we’re using the same REST URI, but depending on the endpoint, hitting different services in the backend. You could also connect to multiple services and transform those responses to a single response.
API Gateway
MicroservicesA way to encapsulate business function into smaller moving pieces.
Pros:● Can be upgraded, swapped out, refactored, rewritten to heart’s content
without affecting other core business functions● Easier to scale and deploy. One moving piece that’s smaller and self
contained.● Easy to build out functionality by only relying on it’s own functionality and
vendors.● Documentation simpler to keep up-to-date.● Testing and mocking business functionality is less complex.
MicroservicesCons:● Increased difficulty to develop - No integration for IDEs to recognize
microservices. Relies on APIs and mock responses.● Making sure services are available - Health checks and recovery for services
is vital or you have a cascade of failure● Service discovery necessary - As services scale up and down, they need to
register machines for the service
Microservices: The Uber Example
Microservices: The Uber Example
Passenger Web UI: Is there a need to know about the Notifications, Payment or Billing systems? This can reduce code logic and complexity to render different sections of the UI.
API Gateway: On mobile, we can render information about the passenger and the driver in one request based on the trip.
Passenger Management: No need to worry about notifications for trips or billing, why have it sit next to the code? Less code to parse during the request, faster response!
Serverless
Event triggered functionality that is completely self contained. Some see this as the next wave of architecture.
Pros:● Saves Ops headaches - No management of servers, it’s now on developer
and provider for performance.● Language independent - Just like a microservice, it’s abstracted away from
other code bases and can be written in the best language for the use case● Ultimate modularity - Lends itself to the fastest way to do one specific thing.
Best for games of code golf!● Potential for cost savings - Most providers price per function run and memory
footprint, no instances
Serverless
Cons:
● Code management complexity - Knowing which events are changing and deployed must have a system built behind it
● Code footprint - Performance of the function is based on the direct code behind it. Minimize vendor libraries, correct O(n) operations
● Reacting to errors - Mechanisms need to be built around functional failures. You can no longer throw an exception.
● Documentation - Again, knowing what functions do must provide detailed use-cases for all parameters sent to the function or be prepared for a cascade of failure
Serverless
Serverless
Just like hitting a microservice via an API gateway, you could route an endpoint to a serverless function instead.
In this example, the different request method determine which function to trigger. There would be shared code between the functions for saving to the database, but this keeps the functions mean and lean.
Appendix
Links
A list of interesting resources and products:
● Kong: http://getkong.org & http://www.slideshare.net/mashapeinc/microservices-api-gateways
● RAML: http://raml.org
● Microservices: https://www.nginx.com/blog/introduction-to-microservices/
● Nginx Modules: https://www.nginx.com/resources/wiki/modules/
○ Log if: https://github.com/cfsego/ngx_log_if/
○ MySQL interaction: https://github.com/openresty/drizzle-nginx-module
○ Redis interaction: https://github.com/openresty/redis2-nginx-module
○ Health and status checks: https://github.com/yaoweibin/nginx_tcp_proxy_module