[Note: The following post was created by Filip Verloy (@filipv), Technical Business Development Manager at Nuage Networks, based in Antwerp, Belgium. Filip provides an excellent demonstration of how application networks and policies can easily be built in the Nuage Networks VSP system. The post originally appeared on his technical blog here.]
As I’m sure you’re tired of hearing by now, IT is typically divided in multiple silos which don’t always see eye to eye. Sometimes people are afraid of needing to adjust perceived best practices in their own domain to better collaborate with the rest of the organization. In many cases, it’s simply a matter of not understanding because you’re not speaking the same language.
The ideal scenario would be a world where each team would expose it’s infrastructure, built on best practices, through APIs, so other teams could interact with it in the optimal way.
At Nuage Networks, we provide API-based access to our components, making full scale automation a possibility, but we can also bring together teams speaking different languages via our abstraction-based SDN policies.
Nuage Networks Application Designer
Application Designer is built for use by people with an understanding of application constructs that don’t necessarily need to understand, or care about, the underlying networking constructs. These are automatically abstracted by the Nuage platform.
In this example we initially start off with a clean slate; no network constructs have been created beyond the L3 domain.
If we go to Application Designer we can see the application services that are available. These would typically be created by the network team. It is an abstract representation of a network service, for example, below we are creating the application service https, providing TCP communication to port 443.
The application teams can now use these application service abstractions to build out their applications. In the example below, we start by creating a 3-tier application called “Banking App”.
Next, we can start to define and add our application tiers and interconnect them by using the application services abstractions that were previously created by the networking team. You do this by dragging and dropping items from the library onto the canvas.
Once you have your application tiers mapped out, you can use the application services to create flow security policy (what type of traffic is allowed between these 2 points) simply by drawing a line between the 2 tiers.
In this case we are indicating we want HTTPS to be allowed from the Internet to the front-end application tier.
One you have your application mapped out and interconnected (you could also drag and drop other complete applications on the canvas and specify connectivity between those as well), you can add workloads to the tiers. These will then inherit the policies you have applied.
Since the the system will translate these different abstractions to the correct networking constructs, we can look at the network design and verify that our application model has been completely mapped to a set of networking policies.
Furthermore, looking at the security policies, we can see these have been translated as well, making it easy for different teams with different knowledge domains to focus on their areas of expertise, while at the same time bringing everything together via our policy based abstractions.