18
Nginx Conference 2016 Learnings and State of the Industry SEPTEMBER 12, 2016 BEN SCHOLLER

Nginx Conference 2016 - Learnings and State of the Industry

Embed Size (px)

Citation preview

Page 1: Nginx Conference 2016 - Learnings and State of the Industry

Nginx Conference 2016Learnings and State of the Industry

SEPTEMBER 12, 2016BEN SCHOLLER

Page 2: Nginx Conference 2016 - Learnings and State of the Industry

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

Page 3: Nginx Conference 2016 - Learnings and State of the Industry

● 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

Page 4: Nginx Conference 2016 - Learnings and State of the Industry

Nginx

Page 5: Nginx Conference 2016 - Learnings and State of the Industry

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.

Page 6: Nginx Conference 2016 - Learnings and State of the Industry

Analysis of Learnings

Page 7: Nginx Conference 2016 - Learnings and State of the Industry

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

Page 8: Nginx Conference 2016 - Learnings and State of the Industry

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

Page 9: Nginx Conference 2016 - Learnings and State of the Industry

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.

Page 10: Nginx Conference 2016 - Learnings and State of the Industry

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

Page 11: Nginx Conference 2016 - Learnings and State of the Industry

Microservices: The Uber Example

Page 12: Nginx Conference 2016 - Learnings and State of the Industry

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!

Page 13: Nginx Conference 2016 - Learnings and State of the Industry

Serverless

Page 14: Nginx Conference 2016 - Learnings and State of the Industry

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

Page 15: Nginx Conference 2016 - Learnings and State of the Industry

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

Page 16: Nginx Conference 2016 - Learnings and State of the Industry

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.

Page 17: Nginx Conference 2016 - Learnings and State of the Industry

Appendix

Page 18: Nginx Conference 2016 - Learnings and State of the Industry

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