Introducing the NGINX Microservices Reference Architecture

The Microservices Reference Architecture will be made available later this year, and will be discussed in detail at nginx.conf 2016 in Austin, TX, from September 15-17. Early bird discounts are available now.

Author’s note – This blog post is the first in a series; we will extend this list as new posts appear:

Introducing the NGINX Microservices Reference Architecture (this post)

Upcoming posts will cover the use of Mesosphere DCOS services in the Microservices Reference Architecture; each of the three models included in the Microservices Reference Architecture; and the Ingenious photo-sharing sample app.

I’ve written a separate article about Web frontends for microservices applications. We also have a very useful and popular series by Chris Richardson about microservices application design, plus many other microservices blog posts and microservices webinars.

Introduction

NGINX has been involved in the microservices movement from the very beginning. The lightweight, high-performance, and flexible nature of NGINX is a great fit for microservices.

The NGINX Docker image is the number one downloaded application image on Docker Hub, and most microservices platforms you find on the Web today include a demo that deploys NGINX in some form and connects to the welcome page.

Because we believe moving to microservices is crucial to the success of our customers, we at NGINX have launched a dedicated program to develop features and practices in support of this seismic shift in web application development and delivery. We also recognize that there are many different approaches to implementing microservices, many of them novel and specific to the needs of individual development teams. We think there is a need for models to make it easier for companies to develop and deliver their own microservices-based applications.

With all this in mind, we here in NGINX Professional Services are developing the NGINX Microservices Reference Architecture (MRA) – a set of models that you can use to create your own microservices applications.

Our goal in building this Reference Architecture is threefold:

To provide customers and the industry with ready-to-use blueprints for building microservices-based systems, speeding – and improving – development
To create a platform for testing new features in NGINX and NGINX Plus, whether developed internally or externally and distributed in the product core or as dynamic modules
To help us understand partner systems and components so we can gain a holistic perspective on the microservices ecosystem

The Microservices Reference Architecture is also an important part of professional services offerings for NGINX customers. In the MRA, we use features common to both open source NGINX software and NGINX Plus where possible, and NGINX Plus-specific features where needed. NGINX Plus dependencies are stronger in the more complex models, as described below. We anticipate that many users of the MRA will benefit from access to NGINX professional services and to technical support, which comes with an NGINX Plus subscription.

An Overview of the Microservices Reference Architecture

We are building the Reference Architecture to be compliant with the principles of the Twelve-Factor App. The services are designed to be lightweight, ephemeral, and stateless.

The MRA uses industry standard components like Docker containers, a wide range of languages – Java, PHP, Python, NodeJS/JavaScript, and Ruby – and NGINX-based networking.

One of the biggest changes in application design and architecture when moving to microservices is using the network to communicate between functional components of the application. In monolithic apps, application components communicate in memory. In a microservices app, that communication happens over the network, so network design and implementation become critically important.

To reflect this, the MRA has been implemented using three different networking models, all of which use the open source NGINX software or NGINX Plus. They range from relatively simple to feature-rich and more complex:

Proxy Model – A simple networking model suitable for implementing NGINX Plus as a controller or API gateway for a microservices application. This model is built on top of Docker Cloud.
Router Mesh Model – A more robust approach to networking, with a load balancer on each host and management of the connections between systems. This Model is similar to the architecture of Deis 1.0.
Fabric Model – The crown jewel of the MRA, the Fabric Model features NGINX Plus in each container, acting as a forward and reverse proxy. This Model also uses Mesosphere DCOS services. It works well for high-load systems and supports SSL/TLS at all levels, with NGINX Plus providing reduced latency, persistent SSL/TLS connections, service discovery, and the circuit breaker pattern across all microservices.

Our intention is that you use these models as a starting point for your own microservices implementations, and we welcome feedback from you as to how to improve the MRA. (You can start by adding to the Comments below.)

A brief description of each model follows; we suggest you read all the descriptions to start getting an idea of how you might best use one or more of the models. Future blog posts will describe each of the models in detail, one per blog post.

The Proxy Model in Brief

The Proxy Model is a relatively simple networking model. It’s an excellent starting point for an initial microservices application, or as a target model in converting a moderately complex monolithic legacy app.

In the Proxy Model, NGINX or NGINX Plus acts as an ingress controller, routing requests to microservices. NGINX Plus can use dynamic DNS for service discovery as new services are created. The Proxy Model is also suitable for use as a template when using NGINX as an API gateway.

If interservice communication is needed – and it is by most applications of any level of complexity – the service registry provides the mechanism within the cluster. (See this blog post for a detailed list of interservice communications mechanisms.) Docker Cloud uses this approach by default; to connect to another service, a service queries the DNS and gets an IP address to send a request to.

Generally, the Proxy Model is workable for simple to moderately complex applications. It’s not the most efficient approach/Model for load balancing, especially at scale; use one of the models described below if you have heavy load balancing requirements. (“Scale” can refer to a large number of microservices as well as high traffic volumes.)

Stepping Up to the Router Mesh Model

The Router Mesh Model is moderately complex and is a good match for robust new application designs, and also for converting more complex, monolithic legacy apps that don’t need the capabilities of the Fabric Model.

The Router Mesh Model takes a more robust approach to networking than the Proxy Model, by running a load balancer on each host and actively managing connections between microservices. The key benefit of the Router Mesh model is more efficient and robust load balancing between services. If you use NGINX Plus, you can implement active health checks to monitor the individual service instances and throttle traffic gracefully when they are taken down.

Deis Workflow uses an approach similar to the Router Mesh model to route traffic between services, with instances of NGINX running in a container on each host. As new app instances are spun up, a process extracts service information from the etcd service registry and loads it into NGINX. NGINX Plus can work in this mode as well, using various locations and their associated upstreams.

And Finally – the Fabric Model, with Optional SSL/TLS

We here at NGINX are most excited about the Fabric Model. It brings some of the most exciting promises of microservices to life, including high performance, flexibility in load balancing, and ubiquitous SSL/TLS down to the level of individual microservices. The Fabric Model is suitable for secure applications and scalable to very large applications.

In the Fabric Model, NGINX Plus is deployed within each container and becomes the forward and reverse proxy for all HTTP traffic going in and out of the containers. The applications talk to a localhost location for all service connections and rely on NGINX Plus to do service discovery, load balancing, and health checking.

In our configuration, NGINX Plus uses Mesos-DNS to query Zookeeper for all instances of the services that the app needs to connect to. With the DNS frequency setting, valid, set to 1 second, for example, NGINX Plus scans Zookeeper for instance changes every second, and routes traffic appropriately.

Because of the powerful HTTP processing in NGINX Plus, we can use keepalives to maintain stateful connections to microservices, reducing latency and improving performance. This is an especially valuable feature when using SSL/TLS to secure traffic between the microservices.

Finally, we use NGINX Plus’ active health checks to manage traffic to healthy instances and, essentially, build in the circuit breaker pattern for free.

An Ingenious Demo App for the MRA

The MRA includes a sample application as a demo: the Ingenious photo-sharing app. Ingenious is implemented in each of the three models – Proxy, Router Mesh, and Fabric. The Ingenious demo app will be released to the public later this year.

Ingenious is a simplified version of a photo storage and sharing application, a la Flickr or Shutterfly. We chose a photo-sharing application for a few reasons:

It is easy for both users and developers to grasp what it does.
There are multiple data dimensions to manage.
It is easy to incorporate beautiful design in the app.
It provides asymmetric computing requirements – a mix of high-intensity and low-intensity processing – which enables realistic testing of failover, scaling, and monitoring features across different kinds of functionality.

Conclusion

The NGINX Microservices Reference Architecture is an exciting development for us, and for the customers and partners we’ve shared it with to date. Over the next few months we will publish a series of blog posts describing it in detail, and we will make it available later this year. We will also be discussing it in detail at nginx.conf 2016, September 15-17 in Austin, TX (information and early registration here). Please give us your feedback, and we look forward to seeing you.

The post Introducing the NGINX Microservices Reference Architecture appeared first on NGINX.

Source: Introducing the NGINX Microservices Reference Architecture