 Oh guys Wanted to start a session on when network meets up. I think the title speaks for itself It's really talking about the two worlds that was previously disconnected My name is Nati Shalom. I'm the city and founder and I'm gonna talk about mostly on the app side And my name is Samuel Belkovic I'm a product manager in Radware and we specialize in load balancing and security networking equipment So I represent the networking side Okay So from the agenda today, what we'll do is we'll talk a little bit about give the background about Networking an application Present a specific way on how we see things are happening today and then we'll talk about What change why all the this pattern of managing networks as a silo and application as silo is gonna Be changing and then Nati will demonstrate how this actually goes into Work And then if we have time then we'll talk a little bit about the additional things that are being done Okay, so basic definitions I'll be talking about the combination of deploying applications and networking Obviously as application people or people who manage applications when we look at the application Many of us will first look and see what are the application tiers, right? So this is a logical construct Probably most of the application people Are familiar with that next thing is basically to construct. What are the building? Servers whether they are physical logical or physical or virtual and then What's the plurality of them in this topology and then if we zoom into a specific tier into a specific server? How this is constructed what are the requirement? And the first time we will meet the network is basically by specifying how many network cards We need or how many connect VNICs we need What are the required type of IPs? What is the application frameworks that needs to be deployed whether it's a database or etc and what port and protocol and Obviously the application logic the schema or in the database And all this is pretty familiar At least to me when I was handling applications. This is what I would be designing and doing day to day Then the next thing to think about is the logical connectivity obviously if we have tears then how they get connected from a logical perspective and that's usually obviously quite obvious and In that case Usually this is where I would be done, right? This is where I would be Thinking about IPs connectivity is how things are communicating point to point. Okay, and the question is well Where is the network? What are the additional things that are happening either due to the? Application requirements or due to other concerns? So Let's walk over that So the one of the first thing that has an app as a network Designer I'm usually doing is understanding two things whether there's any need for isolation due to security or things like this Or are there any specific requirements from the application side things like multicast requirements or broadcast requirements? And that will usually lead me to the design of the broadcast domain of which nodes need to be on Which broadcast right so we for example we can have a DMZ zone with its own broadcast domain and Back-end zone with its own broadcast domain We could also decide to split it three ways If that makes sense for any reason right? Now the man that we got to that decision or the networking guys have got to this decision The next thing that they will do is there's the definition of the layer three of the connectivity IP connectivity, which is subnets How do you reach out of the subnet gateways the how you manage IPs the IP address management? And what would be providing the DNS services right and this is again something that is when I was an application An application owner didn't care about this right I don't think that I cared is that I'm gonna have my IPs and that everything communicates, but all of this is going underneath it, right? Then we are bringing in another another concerns maybe availability And this is maybe slightly unusual to use a load banter for availability But what would be more interesting is availability and scalability Well, we actually designed how the application is going to be scale or will be available using load bashing technologies Oh such okay, and again, that's something that Many occasions the network admin will design for us and then security requirements, right? File one different paces etc. And again as an application user Most of these are like Chinese to me right those are happening underneath the plane Okay, last thing is this needs to be managed, right? So there's a third networking requirement Which is might be a new broadcast domain with its own subnets with its own tools And maybe this also needs to be connected to the outside for we are VPN so the key here is to understand that as an application in In a standard environment, I'm really not aware on all the other networking moving parts and from that aspect there's very Distinct delegation of responsibility, right there. We have the network or security manager who will manage the Broadcast domains the connectivity all the network services whether the placement and configuration and the network security and Then the application itself, which is the server operating system and all the other stocks, okay? the only strange Beast in this environment might be a load balancer because realistically speaking it is a networking Appliance connected to the network But it has it might have a lot of application based logic, right? It might have things like cookie stickiness based Larry seven routing policies and other application based logic and in that regard it is really a question of what's the right delegation of responsibility there whether it's a Networking manager that does all of this or whether that's the application owner that needs to understand what's what's to do in the load balancer Usually in the standard IT organization the network manager will usually handle the load balancer as a whole, okay? So so far What we understood what we've seen is that you have the application owner managing basically the servers stack application code and care about basic connectivity and Then networking admin who manages everything below that in about the networking concerns security, etc So what's changed? Why is it what why we believe that all this is going to be changed anyone have an idea? Hmm, right. It's even more than that. What's changed is that? Everything has become an API everything become programmatically and now you can orchestrate the delivery of all those things using a single way, okay, and In open stock specifically all those capabilities are actually exposed via the neutron API Things like layer to broadcast domain you can create them on your whim if if this is how you're allowed to You can create layer three subnet you can specify how the IP addresses are being handled there All the other services such as routers gateways nuts you can actually manage also port security, which is more like a Silver-based security, but you can do port security and obviously now you can also control the layer four to seven services Such as load balancing VPN and VIP firewall and all of these has concrete APIs that could be software driven, right? Yeah, and I think that Now that small explain What is the network or where is the network in all of our application? I think that one thing that was clear even to me while working on those slides That there is a lot of networking out there that we usually as an application guys don't really care about or Don't deal with and mostly They are done statically like someone configure the pre configure them for us somewhere even in the cloud world Like we don't necessarily create villains on the fly when you don't necessarily and we don't usually create public IPs and floating IPs that often and we kind of Work differently in a public cloud, but still it's relatively static to what we have today and and as Small mention the real potential here to really change the world We live in in terms of application deployment is that now we can merge the two It's very similar to what happened in DevOps Remember previously to that we have application owners and we have operational guys that are dealing with management of the application itself And the two didn't really connect and there was a lot of silo isn't built into that process just because of their organizational barrier And over a sudden cloud came in and now developers have direct access to the infrastructure Which means that they can bypass the operations and do their own stuff the same thing is gonna happen here and The fact that we have access to the API Would also drive a lot of change in culture and the way we do things and we'll talk more about it towards the end of that Presentation now to actually make it real rather than a philosophical discussions. We're gonna run two types of examples Both doing the same thing one of them is based on a specification that is called Tosca And the other one is based on a open stack heat. How many people are familiar here with the heat raise their hand Okay, and how many people are familiar with Tosca? Good, so I'll just say a few words on Tosca and then less on here because it looks like most of you are familiar with that I Would say at the beginning both of them are descriptive language in which you write a blueprint in some sort of a DSL programmatic DSL and then you could tell an orchestration engine to take that DSL and execute your deployment in our Specific case the DSL will include both the application specification and the network specification that maps to the Neutron calls and so forth The difference between the two is that in the Tosca world This was actually built in a way that is not specific to open stack So it was actually built in a pre open stack world And it was built to provide a standard blueprint that will fit into many environments Not just open stack and it takes if you'd like a more top-down approach towards the problem starting from the application The dependency of the applications There is a lot of that thought on how we orchestrate application manage the dependencies and all the nodes as such of that Where heat came mostly as the equivalent of cloud formation the Amazon cloud formation Trying to map the existing if you'd like model that Nova have and all the different services within open stack have Into a descriptive language and then it grows up the stack From that point onwards and now what we could see is also And I'll talk more about it kind of a marriage between the two models and I'll talk a little bit about that That's why I wanted to show the two separate examples on the example side, I'm gonna run a typical deployment of That you'll see a lot in examples We actually taken the heat WordPress example and added networking piece into that So that's kind of the standard WordPress example that you will find over the web Plus networking attached to that that's kind of would say the heat version of the example that I'm going to show right now And what you could see is the networking element attached to each of the nodes So even though we're talking about two nodes You could see that there is quite a amount of networking elements built into that and that's kind of a typical deployment It's not something rare. It's something that most of us do it. We just don't think about it in that way Oh, we're not doing it in an automated fashion So for example in a database side, we have a villain specifically that talks to the web container the WordPress container We don't want that Network to be open to the public network. So we created a separate network for that Obviously, we have a subnetwork for that and a port that will allow the two to connect and a setup of a security group Which you'd like. It's a host level as a firewall on the Upup server the apart server, which is facing the world You could see that we have additional more components and the additional components is because we need not just to connect between the web Container database is because we need to connect to the outside world. Therefore. We have things like broader And things that are related really to floating IP Which means that we need to connect to a public DNS and The IP address that we're using needs to be accessible over the internet and that's why we need to have that available to us This would be the the topology view. So when I run that I'll actually show that on the heat side when I deploy it with heat That's the outcome of that. We'll see that in a second But what we could see is the two side of networks That we have here the application network and the database network and you could see that the application network has a leg to the Public router and that's where we have those two separate networks So with that I'll jump into the heat Reference here and the live example Obviously for the sake of time what I did is I actually ran Heat on dev stack on one of the machines. Let me just set it up Okay, so what we can see here is a deployment that I did on dev stack and I already logged into the Dev stack horizon console I took the WordPress blueprint that I think I refer to earlier on and I basically use the command line or the The online version of the command line to actually deploy the application at the world press application What we can see here is the networking elements because of resolution You wouldn't see the entire screen Which basically shows all the nodes That I described in the deployment itself and let's see how the resources it looks like and how many resources do we have here? So obviously we have the network resource for the data Subnet the WordPress Apache instance the MySQL instance and I wouldn't go through all of them But basically for each element in the graph We create an element in the DSL itself and then we create the connectivity between them using References get parameters and some other stuff that heat model uses so the way I express Relationship if you'd like in a heat template is that I'm using a get parameter from another resource and that get injected Into another resource and create a dependency graph The lines that you could see on that graph is actually representing in the topology Not the actual network connectivity, but the dependencies in the graph So for example when I'm doing a get parameter from a node that creates a dependency that creates a line in that graph That's kind of the way it looks like but the important thing is that I was able to take a description I put it in one document and in one click create both the network setup and the application setup and connect all of Them together that's kind of I think the important thing that I wanted to demonstrate here And that can be done with it even today The second example is based on Tosca switch back to the slides and what we will see is Similar example. Oh before that, let's see the how the blueprints looks like So what you could see in the blueprint itself. What did I put the laser thing? That's right somewhere So what you can see here is the following thing We can see that we have and I actually took a snippet of that DSL and and focused on the network elements in the heat DSL What we could see is that we have here For example the definition of the network itself the tenant idea of that network Then we can see the subnet which is the actual network and the definition of the public DNS So this would be the network that talks to the internet and in that case We are connected to public DNS's that will give us the public IPs and their location pools That is a result of that then we can see the actual ports That each of the nodes will be connected to and how we were basically using the get parameters to get references From those and network elements and network nodes into our existing nodes That's how a DSL would look like obviously. It's a little bit longer, but I think you get the idea The second example would be a Tosca like example the reason why I'm saying Tosca like is because Tosca itself is still evolving Both heat and Tosca is still evolving So I took obviously a snippet plus some extension that we've done I'm going to use cladify which is the engine or the implementation of that Tosca Deployments and I'll use that as the tool to actually drive the example itself So similar to the previous example. We have the same network elements plus the addition of an additional Monitoring and logging network. So that's kind of just to make things more interesting cladify uses that as a default Again, just to make things more interesting I'm not using the same wordpress example But a very similar example using MongoDB as a database and no JS as a front-end and we have the same kind of Rado setup and if we really look at the network topology in this case, I'm actually running on the HP OpenStack Cloud and I took a snippet of that I'll show you how that looks like what we could see is again the admin network and the application network similar to the Previous example plus the administration network and we can see that there is a connection to the router similar to the previous example that we have here The so the other thing that I added here is another node that is the management node that basically listen to everything that Goes here and you could see that it actually plugs to all the network Elements and it will do the logging and monitoring on that And if we look at the topology view of that and I'll show you how that looks like live We'll see a screen like that. So let me show you that Live obviously I already deployed the application because it didn't want to spend a few minutes just to see circles Turn it around What I'm gonna start with is The deployment itself. No limit. Oh, okay. I didn't know that it forgets the display setup Okay, so what we can see here is the topology view That is a result of the fact that I took a toss car based Yamel. Let's see how that Yamel would look like Look something like this. Okay, so basically Looks very similar to the heat one With the several differences that I'm gonna spend some time on The interesting thing is that I can see all the elements the host itself The database and you'll see the networking piece Assessor with that and the relationship. I have a slide on that. So I'll zoom into that, but What I'm gonna use here is a topology view because it's more it's easily to look into that and what we can see is that there is a reference between a node and a Relationship between that node that is contained within a certain host So one of the things that toss case taking from an application centric view is a relationship for example Then we have other things that describe policies and other things that describe alerts and all other things that currently in heat Are not descriptive enough if I would like there are ways to do that, but I'm not descriptive enough So in this case, for example, I could say that the node JS node needs to live within the node JS VMs and it is connected to a Mongo D node which is Hosted in a Mongo DVM and I can describe also the software components Relationship at that level of granularity Okay So what we can see already is the differences between heat and Tosca at least right now is that Tosca tried to provide more granularity on how we define the software components and how they relate to the network components Versus in heat it's mostly coming from the infrastructure view where we define the The nodes in the system and the dependencies and the connectivity Kind of becomes an after effect if you'd like of the fact that I actually did a get parameters For one node to another that created the relationship Okay, so let's see how the actual deployment looks like in Horizon this would be a set of machine that I described I think I showed you that and we can see later on the list of Nodes here. So if I go to the deployment View so the first view that I showed is the actual blueprint itself So I loaded the metadata of the blueprint There was no real execution behind it and I can create different deployments out of that definition I could create deployment one deployment to deployment three or whatever that's kind of a clarified way of doing things and The second view is the actual deployment So right now what I'm monitoring is I'm using the same modeling and Mapping it to the physical devices and the state of those devices. I can see graphically very easily What is the state of the actual VM that is running? What is the actual state of the component that is running and what is the state of the connection between those nodes and so forth and so forth That's kind of the give you the idea of the mapping between a model and that and because in Tosca I can define that level of granularity. It's much easier to actually see those views up to the software components level At the very granular level. Let's go back to the slides and see how take a more closer snippet into the actual DSL Okay So in a Tosca like example the DSL would look something like that You could see that it's more descriptive a little bit because of because the language is more explicit in terms of relationship And so and you could see that for example, I wouldn't go through the entire components But I have for each element It's called the node and I have a name for it and type for it and I can define different level of types But there is something that is called relationship and the relationship could be contained in For example in the case of the neutral network, it could be the It could be another relationship which could be in this case a dual relationship Which could be contained in and depends on so depends on would mean I Wouldn't start that node or that element before that other nodes starts and then I'll be connected in so I can define several levels of relationship per node in this case and as I said It's a little bit more descriptive in that level of granularity and the result is that it's also more readable and easier to pass So back to Okay, so what we've seen so far is although there are two types of capabilities managing and driving the network via software and Also deploying the application now obviously there's some more nice use cases that we can program at Leakey address and one of the more spoken about how you actually add the notions of auto-scaling and availability into this and As an example, that is that when you deploy your Heat-hot template or Tosca that is that you also include policies around Existence of a load bouncer and how it would behave so when the application gets deployed a VIP get provisioned And since you actually want this application to be highly available you can use a load balancing solution that provides high availability and Isolation for the tenant Based on the provisioning of such highly available load balancing solution the load balancer gets provisioned and configured and then using a scalability policies that can Measure the performance of the application or other KPI such as CPU The policy could either add VMs while programming the load balancer or remove VMs while also Programming the load balancer and heat actually has such a very aggressively has such a nice example What is what is available in this example is that if you can well if you if you can see the idea is that you have the top-level items that actually define the policy they define which object is going to be Elastically measured how to measure it up how to add things up when how to scale down and what are the KPIs and then it Also has the definition of the load balancer Such as the monitor poor etc. And all this leads to not just being able to deploy an application But also to Continuously measure how it performs and then scale it So So far so good. So we see that we have systems that enable you as an end as a programmer as an application or not just to own your application stock but also own all the Available requirements from the network, but this actually might open to some more Discussions Yeah, so if you really consider More real-life scenarios things that you would need to deal in terms of concrete use cases that are actually very popular It's the continuous availability for example in that case You need to worry about the availability zones for example and making sure that nodes are not running on the same availability zones or region Which is also a network function if you'd like and how do you do that? And how do you map that into a DSL in an automatic fashion? You need to make sure that if we have a database and it's connected to a storage or a block storage that block storage would be running in the same availability zones as my application because Something that I don't want to happen is that the block storage would be an L Availability zones and my application would be in another ability zone So how do I create and map those most sophisticated relationship if you'd like and the same goes with continuous deployment? That system needs now up and running and yes, I can and we've shown it today I can easily create that environment and automate both the networking and the application piece How do I actually maintain it maintain it in the sense that I need to do upgrades monitoring of those upgrades? Increase the capacity of that environment and so forth so this is the real-world kind of things that we need to worry about and Just to give you an idea of a real-life examples actually that was presented here in in the open stack summit an example of The HP print example, so what you can see is some of the numbers of the use case and those are real so they were actually coming from an Amazon deployment that we're using chef and transition to the open stack on HP public cloud based environment So kind of the the the process that we've gone through in that process using the the cloud if I product to actually map that Deployment that they have in Amazon into that included Plugging into the neutron API and creating all those nice network setup And also plugging into the chef deployments and the existing artifacts so that they wouldn't need to change a lot of things when they do that transition and The result looks something like this Okay, so you could see that real-life examples Would map and this is actually taken from a real life snapshots of their environment so we could see a lot of network elements being created in their environment to be managing that and We can actually use the same techniques that I showed on the example earlier Not just for examples, but to deploy real life more complex kind of deployment. So it's real. It's not something It's not artificial. It's not a demo. It's not something futuristic It's something real that can be applied today to application today And that's kind of the reason why I point it to that now if we really look at the future work This is the thing that I'm working on This is my dream world But I'm not gonna talk to you about that right now Unfortunately There are a couple of things that are Taking place and actually this summit was This those type of topics was fairly hot and this discussion By the way, there would be references on the slides for both the demos So you could download the demos and run it yourself both the heat demo than the clarify demos So don't worry about the references And there is a there is a ongoing project, which is the Tosca project Tosca processor project as it is called which transform a Tosca based DSL into it I'll give you the reference to that that's one aspect to get heat and Tosca closer together so that we can benefit from both worlds heat as the infrastructure modeling and And Tosca as the application modeling language The second work that is done is within heat so that we can create a transformation Into that Tosca from Tosca into it. There are certain capabilities like the ability to run actions dependencies and so forth That was missing and heat is adding it to its own hot Specification and that case that means that from a feature set perspective It would be easier to map a Tosca model into heat So Tosca would be if you'd like that the portable version of a modeling that can plug into heat And that case we can benefit from both worlds and the last point is that within clarified the the version that I showed here was running actually with our orchestration engine and the work that we're doing and actually There's a lot of discussion that we're having and I'll be more than happy to hear a lot of views or the views from you Is ready to run all that example directly on heat So in that case qualified could provide all the monitoring a nice gooey around heat and give you that full experience With the logging and log stash and elastic search behind the scenes And it would still use the same heat engine and the same heat templates and connected directly as part of the deployment That's something that we're planning to do for the next release On the area of networking one of the I think one of the more interesting works that is currently happening And to me, it's quite promising is group-based policies Which to me addresses two key things eat first and elbows the application user to actually express their requirement in a more high-level way than just specifying things like Broadcast domains and there three which on many cases doesn't make sense in the dialect and on other Allow the network admins to actually specify Their policies and requirements in a way that when you actually deploy eventually the solution you get both the Expertise of the networking on how it needs to be secured how it needs to be Efficient with a requirement of the application and this is obviously a work in progress. It started from the open daylight project And it also has now an API that is work in progress in the neutron project and I suggest that you Look at it because it might be again something that changes the way we operate Yeah, and I think with that we kind of Wanted to open the the discussion for questions as I mentioned there is a list of references for the examples Watch out for the get clarify hashtag or open stack hashtag I'll be publishing the actual reference to those slides a few minutes after the session ends So let's see if there are any questions from the audience was everything clear Okay, so I see you are nodding Do you have a question or not? Or do you want to be the first one to ask questions? Yes, if you can go to the mic so that others will hear that I Just had a question about rolling this out organizationally if you had any tips for sort of helping people adopt change and Obviously this can be a radical change for some people I'm gonna take this one. So I've seen organizations that although automation can take place They don't really allow application users to manage the network and network people to do stuff for the application It's still You still get a delegation for responsibility. You just use the API to Accelerate the way you provision or you give you give you you create the artifacts for the service. So from a Process perspective, it's still using the very similar process where people might be using via phone of the ticketing systems But the frequency of on both of how both organizations could deliver their Requirement or their artifacts becomes much faster. So this is one way to address them This one this this change does that answer question? Okay, and I think if I would add to that It's very similar to the experience that we have with DevOps, right? It's a culture change and and so forth and the lessons from that experience was that one It's inevitable if you want to really get to that level of agility It will happen, you know regardless if you want it or not it will happen Once developer have access to an API that will use it and they will try to bypass Barriers and there is no much weight that you could put borders for a long time and say, you know Here's your API, but you're not allowed to use it practically speaking It will break at some point and sooner than you think so the right way to deal with that is embrace the change and Accept the change and I think we have experience with DevOps on how to do that By for example having the networking team the networking and I know it knowledge is part of the application team Things on that line that will make the the to work together in a way that wouldn't replace the other because still a Lot of that knowledge of how to set up network is important and not all people not all the developers would now have that Even though they have access to the API So I think we can apply the same kind of lessons from the DevOps world on how we Change the operational model and how we do things into the networking world and that's another group that is now becoming part of that change That was an excellent question by the way any other question good. So thank you very much