[ngx_snippet name=’table-style-blog’]
Author’s note – This blog post is the fourth in a series:
All six blogs, plus a blog about web frontends for microservices applications<.htmla>, have been collected into a free ebook.
Also check out these other NGINX resources about microservices:
The Fabric Model is the most sophisticated of the three models found in the NGINX Microservices Reference Architecture (MRA). It’s internally secure, fast, efficient, and resilient.
Like the Proxy Model, the Fabric Model places NGINX Plus as a reverse proxy server in front of application servers, bringing many benefits. In the Router Mesh Model, NGINX Plus instances within the microservices application act as central communications points for other service instances. But in the Fabric Model, there is a dedicated NGINX Plus server instance in each microservice container. As a result, SSL/TLS security can be implemented for all connections at the microservice level.
Using many NGINX Plus instances has one crucial benefit: you can dynamically create SSL/TLS connections between microservices – connections that are stable, persistent, and therefore fast. An initial SSL/TLS handshake establishes a connection that the microservices application can reuse without further overhead, for scores, hundreds, or thousands of interservice requests.
Figure 1 shows how in the Fabric Model NGINX Plus runs on the reverse proxy server and also each service instance, allowing fast, secure, and smart interservice communication. The Pages service, which has multiple instances in the figure, is a web‑frontend microservice used in the MRA.
The Fabric Model turns the usual view of application development and delivery on its head. Because NGINX Plus is on both ends of every connection, its capabilities become properties of the network that the app is running on, rather than capabilities of specific servers or microservices. NGINX Plus becomes the medium for bringing the network, the “fabric”, to life, making it fast, secure, smart, and extensible.
The Fabric Model is suitable for several use cases, which include:
As an increasing number of apps use SSL/TLS to protect client communication, it makes sense for backend – service‑to‑service – communications to be secured as well.
The use of microservices for larger apps raises a number of questions, as described in our ebook, Microservices: From Design to Deployment, and series of blog posts on microservices design. There are four specific problems that affect larger apps. The Fabric Model addresses these problems – and, we believe, largely resolves them.
These issues are:
The Fabric Model is designed to work with external code for container management and for service discovery and registration. This can be provided by a container management framework such as Deis, Kubernetes, or DCOS; specific service discovery tools, such as Consul, etcd, or ZooKeeper; custom code; or a combination.
Through the use of NGINX Plus within each microservice instance, in collaboration with a container management framework or custom code, all aspects of these capabilities – interprocess communication, service discovery, load balancing, and the app’s inherent security and resilience – are fully configurable and subject to progressive improvement.
This section describes the specific, additional capabilities of the Fabric Model, discussed in the previous section, in greater depth. Properties that derive from the use of NGINX Plus “in front of” application servers are also part of the other two Models, and are described in our Proxy Model blog post.
The Fabric Model is an improvement on the typical microservices approach to service discovery, load balancing, and interprocess communication. To understand the advantages of the Fabric Model, it’s valuable to first take a look at how a “normal” microservices app carries out these functions.
Figure 2 shows a microservices app with three service instances – one instance of an investment manager service and two instances of a user manager service.
When Investment Manager Instance 1 needs to make a request of User Manager Instance 1, it initiates the following process:
In the Fabric Model, the service discovery mechanism is entirely different. The DNS resolver running in NGINX Plus maintains a table of available service instances. The table is updated regularly; NGINX Plus does not require a restart to update the table.
To keep the table up to date, NGINX Plus runs an asynchronous, nonblocking resolver that queries the service registry regularly, perhaps every few seconds, using DNS SRV records for service discovery – a feature introduced in NGINX Plus R9. When a service instance needs to make a request, the endpoints for all peer microservices are already available.
It is important to note that neither NGINX Plus nor the Fabric Model provide any mechanism for service registration – the Fabric Model is wholly dependent on a container management system, a service discovery tool, or equivalent custom code to manage the orchestration and registration of containers.
The table of service instances maintained by the NGINX Plus DNS resolver is also the load‑balancing pool to which NGINX Plus routes requests. As the developer, you choose the load balancing method to use. One option is Least Time, a sophisticated algorithm that interacts with health checks to send data to the fastest‑responding service. (Generally, health normally run asynchronously in the background.)
If a service has to connect to a monolithic system, or some other stateful system, session persistence ensures that requests within a given user session continue to be sent to the same service instance.
With load balancing built in, you can optimize the performance of each service instance – and therefore the app as a whole.
SSL/TLS connections in the Fabric Model are persistent. A connection is created, with a full SSL handshake, the first time one service instance makes a request of another – and then the same connection is reused, perhaps thousands of times, for future requests.
In essence, a mini‑VPN is created between pairs of service instances. The effect is dramatic; in one recent test, fewer than 1% of transactions required a new SSL handshake. (It’s important to note that even though the overhead for handshakes is very small, SSL/TLS is still not free, because all message data is encoded and decoded.)
With service discovery and load balancing running as background tasks, not repeated as a part of each new transaction, transactions are very fast.
Here’s how connections are created and used for the same operation outlined for the “normal” process:
With the application health check capability in NGINX Plus, you can build the Circuit Breaker pattern into your microservices app. NGINX Plus can send a health check to a specific endpoint for each service instance. You can define a range of responses and have NGINX Plus evaluate them using its built‑in regular expression interpreter.
NGINX Plus stops sending traffic to unhealthy instances but allows requests that are in process to finish. It also offers a slow‑start mode for recovering service instances, so they aren’t overwhelmed with new traffic. If a service goes down entirely, NGINX can serve “stale” cached data in response to requests in order to provide continuity of service even if the microservice is unavailable.
These resilience features make the entire app faster, more stable, and more secure.
To sum up the differences, and highlight some of the advantages of the Fabric Model over the “normal” process, this table compares how each works for major app functions.
Normal Process | Fabric Model | Comparison |
---|---|---|
Service discovery happens after request is made; wait for needed URL | Service discovery runs as background task; URL available instantly | Fabric Model is faster |
Load balancing happens after request is made; primitive techniques | Health checks used for load balancing run in the background; advanced techniques | Fabric Model is faster, more flexible, and more advanced |
New nine‑step SSL handshake for every service request and response | Persistent “mini‑VPN” with few handshakes | Fabric Model is much faster |
Resilience poor; “sick” or “dead” services cause delays | Resilience built in; “sick” and “dead” services isolated proactively | Fabric Model is much more resilient |
Table 1. The Fabric Model is fast, flexible, advanced, and resilient
The difference between the Fabric Model and the “normal” process is strongest in the most‑repeated activity for any app: interprocess communication. In the “normal” process, every request requires a separate service discovery request, a load‑balancing check, and a full nine‑step SSL handshake. For the Fabric Model, service discovery and load balancing happen in the background, before a request is made.
In the Fabric Model, SSL handshakes are rare; they only occur the first time one service instance makes a request of another. In one recent test of an application using the Fabric Model, only 300 SSL handshakes were needed to establish interservice connections for 100,000 total transactions. That’s a 99.7% reduction in SSL handshakes, delivering a strong boost in application performance while maintaining secure interprocess communications.
With the Microservices Reference Architecture still in development, there are two approaches you can take to begin implementing the Fabric Model today:
The Fabric Model networking architecture for microservices is the most sophisticated and capable of the MRA models. NGINX Plus, acting as both the reverse proxy server for the entire app and handling all ingress and egress traffic for each individual service, brings to life a network that connects service instances.
In the Fabric Model, stable SSL/TLS connections provide both speed and security. Service discovery, working with a service registry tool or custom code, and load balancing, in cooperation with a container management tool or custom code, are fast, capable, and configurable. Health checks per service instance make the system as a whole faster, more stable, and more secure.
NGINX Plus is key to the Fabric Model. To try NGINX Plus, start your free 30-day trial today or contact us to discuss your use cases.
"This blog post may reference products that are no longer available and/or no longer supported. For the most current information about available F5 NGINX products and solutions, explore our NGINX product family. NGINX is now part of F5. All previous NGINX.com links will redirect to similar NGINX content on F5.com."