“In the land of microservices, the network is the king(maker)”
— Sudip Chakrabarti, Lightspeed Venture Partners

Introduction

Microservices style applications are becoming popular as they enable fast delivery. With a microservices-style architecture a single application is decomposed into several components, all communicating over a network. To succeed with Microservices, requires proper management and control of the network.

Within a Microservices style application, individual services need to be allowed talk to some selected sub-set of services, or a particular service version based on the developer’s intentions. A critical requirement in microservices is the ability for developers to precisely control which other services can access his/her deployed service.

When it comes to selecting a Container networking solution there are many options available from projects such as Libnetwork, Calico, Weave, Flannel, Contiv. Nirmata chose to integrate with Contiv because of the rich feature set provided by the model adopted by Contiv. Contiv provides a central management plane and effectively decouples it from the distributed forwarding plane. Contiv also provides decentralized and distributed security for individual services. Contiv exposes a rich set of API’s to configure physical and virtual infrastructure with intent based operational policies provided by Nirmata application blueprints. This blog post will describe how Nirmata integrates with Cisco Contiv networking, to easily manage networking with security policies for a microservices style application.

Figure 1: Contiv overview

source:http://blogs.cisco.com/cloud/why-containerize

Overview

For this post, I will use a Java Tomcat based demo application we created, called Shop4Me. This application consists of 5 services that emulate an eCommerce website, and the Nirmata Service Gateway. We will deploy this application in AWS cloud using Nirmata SaaS with Contiv networking supported.

The Nirmata Agent, running on each host talks to logically centralized Contiv modules and configures networking for the complete environment under one tenant. Netmasters’ APIs help in configuring Netplugin and adding open flow rules on the hosts for all the services in an environment. The Contiv docs provide details on the architecture for using Netplugin and Netmaster developed by Contiv team as a third party Docker networking Plugin.

There is no denying the fact that deploying distributed applications in a cloud environment is hard! It’s even harder to manage applications across multiple environments, and keeping them secure can become a nightmare. Developers want to deploy and manage services without dealing with infrastructure level abstractions details like IP addresses and port mappings.

This is where Nirmata and Contiv come to the rescue. Contiv helps in managing the east-west traffic among different services by configuring the underlying infrastructure and provides mechanism for controlling traffic using policies. Nirmata helps in deploying these applications across multiple hosts and interacts with Contiv networking to provide a complete end-to-end solution with networking baked in. Nirmata makes it easier for developers to deploy, scale up/down their service, update routing policies, run multiple version of same service and a full control over version based routing.

The following diagram shows how a Shop4Me application has been deployed across hosts. We have used two hosts in AWS cloud and the Shop4Me application consists of multiple microservices all front-ended by Nirmata Service Gateway.

Figure 2: Shop4Me application deployment across a two node setup.

How do Nirmata and Contiv work together?

Nirmata and Contiv both supports multi-tenancy. With Nirmata, an environment is a logical concept and multiple environments can securely share a pool of cloud resources. Each environment deployed in Nirmata will automatically create a new network in Contiv model, which is equivalent to a virtual private cloud. All micro-services applications, that are composed of multiple tiers in one environment are part of this isolated network, and policies are used to further control the networking. Users can clone an existing environment on the same infrastructure with completely isolated services between the two environments. This helps in achieving better resource utilization and provides an option for running isolated development and test environments on the same infrastructure.

Each individual service (tier) in micro-service application deployed using Nirmata is mapped to an End Point Group (EPG) in Contiv, which provides the benefit of grouping similar services and policies can be applied across different tiers as compared to applying policies to individual containers. An endpoint group represents one scale-out instance of an application tier, that is likely composed of an elastic scale-out set of containers.

Nirmata also allows configuring routing among the service, to selectively allow and deny traffic. This gives tremendous control to a user and ensures that only selected services can talk to their services. Policies can be applied while deploying the application, or at runtime without a need to start/stop any service or having to manually add access rules on hosts, or blocking/unblocking ports for services.

The following diagram shows the mapping between Nirmata and Contiv models:

Figure 3: Nirmata and Contiv Model

Technical Details

All the services, which are distributed across two hosts, are using VXLAN overlay networking. All the services are part of one network, which is equivalent to one environment, and each tenant can have multiple such environments dev/test, staging or production for example, completely isolated from each other. Gateway service is connected to default Docker network and a network created by Netplugin for this environment, this how outside world can access these services through the gateway. Each environment can have an individual gateway and serve the outside world.

Following figures 4 and 5 show a microservice-application deployed using Nirmata and the virtual network created across the hosts for an application environment, respectively. netctl used – is a CLI wrapper around REST interface provided by Contiv that can be used to manipulate, inspect various objects exposed by Contiv model.

Figure 4: Shop4Me Application deployed through Nirmata

Figure 5: Shop4Me Environment Network created by Contiv on the hosts

Key Points:

o   Shop4Me application environment is equivalent to a Contiv network named Shop4me, with user defined subnet range.

o   Each service is part of an End Point Group in Contiv terminology.

o   Rules are added to the policies, which are applied to each end point group for routing traffic.

Services don’t require mapping ports to the hosts, as services communicate with each other on layer-3. This saves a lot of effort required to manage port mapping for each container and assigning dynamic host ports to the services. This feature also provides a built-in service discovery using SkyDNS. Contiv deploys one DNS container per tenant, which helps to scale well and allows achieving service discovery across environments.

Service Isolation

One of the key requirements as mentioned above is isolating traffic among services. Nirmata provides the capability for version based routing. An environment can consist of multiple versions of the same service, while deploying the environment user can define white and black list for traffic among services based on each service version. Let’s consider a following example:

In this tiny environment service A is running two different versions, when service B communicates with service A, it should only be able to talk to version 1 for service A. However, when service C communicates, request gets load-balanced between both the versions of service A. This helps in keeping both the services in same end point group and with the same      DNS name.

Figure 6: Version based routing flow

These rules get applied as policies for each service, which is equivalent to an End Point Group in Contiv terminology. Each policy can have multiple rules and each group can be applied multiple such policies. These updates to policies can be done while application is running; this doesn’t require any IP table rule changes or port mappings changes to be done. All of this can be achieved at runtime with no disruption to the services already running.

Figure 7: Nirmata UI for defining routing rules across service in an application

Summary

Nirmata and Contiv are a powerful combination. You can deploy completely isolated application environments across the same infrastructure pool using Nirmata. Nirmata enables version-aware routing across services in same application environment. Contiv policy model, among various other things, provide secure services by enabling policies which define which other services are able to access a service; Nirmata dynamically maps changes to network policies to allow, or block, traffic without restarting any services. All of this, with a few clicks of a mouse and without dealing with host command lines, IP addresses or port mappings!

In the future, we plan on exploring Contiv’s volume plugin for storage orchestration as well as advanced networking features such as bandwidth and prioritization through policies, and application connectivity stats provided by Contiv. To achieve better performance Contiv also provides a routed mode. I am also closely tracking the IPVlan plugin added in Docker 1.11 as an experimental feature.

How are you networking your application containers?  Feel free to reach out anytime at prateek@nirmata.com.

Interested in learning more?










For more updates and news follow us at: