 All right. Thank you guys for joining us. So just a quick intro. I'm Jamal Arif. I work for PrumGrid as a solutions architect. PrumGrid basically is a networking solutions provider for your container or open stack clouds. Our booth is right over there, right on that corner. We would be happy to actually give it if you have any queries, any questions. We'd be happy to give any answers on those. So today, what I'm going to talk about is that what are the challenges that you see when you are operationalizing the networking layer of your container or open stack clouds, and how PrumGrid's Cloud Apex can mitigate those some of the challenges that you face. One thing that I want to start about today is that the transformation that you are seeing within the cloud, especially from an infrastructure perspective. And then this transformation in your infrastructure is having quite a major impact on your networking. How do you support your networking? How do you operate your networking services? Now, with this transformation, each level of transformation brings a newer technology that is being adopted by the infrastructure teams, by your infrastructure. And each newer component, each newer product that actually becomes part of your infrastructure adds a level of complexity to your infrastructure. And then that level of complexity has its own learning curve, if you may so. So in most of the cases, the first level of defense, the first line of defense from an operational point of view is your network team, is your network operations team. And since the newer adoption and newer technologies, they don't have the right set of tools then the expertise to actually provide that level of support, provide that level of defense, that first level of defense for your infrastructure. Now, I talk to a lot of customers and a lot of them have their feedback that how do you solve that piece of puzzle for them? How do you provide that tool set, that level of expertise to your network operations team to provide that solution so that they can support the infrastructure? Now, from a networking perspective, the networking services model is also changing. It used to be that each physical box in your, each physical box was specifically for a particular network service. But since now, right now, we are actually moving to a model which is software driven. So mostly it's your software, it's your logical software, which actually is providing those network services for you. So what you have right now is you have, sorry about that, yeah. So you have your physical resources at the bottom and you have your virtual resources at the top. Your physical resources at the bottom is your traditional hardware, like your physical routers or your physical switches. And at the top is your logical construct. So you have your logical constructs of bridging, your logical layer three constructs, and so on and so forth. So from a networking perspective, your physical, so you still have two layers, you have multiple layers. You have a physical layer and then you have virtual layer. Now, if you look at your network operations team, they are pretty much used to work, providing support for your physical layer. That is, it's a physical entity, so it's a physical hardware box. You log into that hardware box and inspect the routes, inspect the VLANs and ports and switches and all those things. But from a logical construct, it's completely different. Now, that logical construct of bridging or a logical construct of router is not a physical entity. It's not living at a particular space. It can live across your data center at one place or at a hundred of different places. Since it's physically not present, but it's a logical entity, it's an intelligent piece of software running in your virtual layer. So you can immediately see that how difficult it would be to actually correlate these two things. And I talked to a lot of customers, and most of the time, the bigger concern that they have is that how do you transform their network operations team knowledge in the physical world to a virtual world where there is so much difference from an operational point of view from a support point of view. Now, in addition to this, most of the services out there which try to solve different issues related to cloud are based on overly networking models. What it is is that it's basically encapsulating your workload traffic into some form of tunnels so that you decouple your physical resources from your virtual resources. So even in Pramkir's case, what we do is that we provide VXLAN-based tunnels to decouple your physical resources from your virtual resources so that your physical stuff, your physical hardware remains static. You set it up once, and you never touch it again, and your virtual layer can then be used to satisfy requirements around security and micro-segmentation in a distributed manner. So we use the VXLAN-based tunneling mechanism, and we have our data plane component, which is known as the IWISER. IWISER is an open-source Linux-based community project. This actually is our data plane component and provides the tunneling for us and also then all the edit functionally on top of it, networking, security, and policies, and whatnot. So basically, there is an additional layer of complexity that arises when you're using the overlay networking models. So when we talk to a lot of customers and since our inception, a lot of the feedback, the major feedback from many of our customers was around how do you go by providing a solution that can help you operate and maintain your cloud? So during a design phase, we started looking at some of the options which are out there from an operational point of view for your cloud. And a lot of the things that we found out were either too much text heavy or in a tabular format. So the information is there. I don't mean to say that the information is not there. The information is definitely there, but it's not easily consumable. We don't want that people, that people, somebody having a lot of expertise or PSDs in SDN and OpenStack should be able to solve those. The information out there should be easily consumable for everyone for your operations teams who can actually start maintaining and operating your cloud from the get go. And that was one of the major goals for us. How do we solve that piece of puzzle? How do we create a solution that is easily consumable by your networking, by your operations team, by your networking team? So together with the, and since we talked briefly touched upon the iOSR part as well, since we already run inside the kernel, we have that visibility over the cloud, right? We have that iOSR kernel component which is running inside the cloud, which is running inside the hypervisors of your computes. So we have the visibility. We have all the information. And using that information, we took a revolutionary approach towards cloud visualization and monitoring platform. So together with that SDN platform, we created a clumb-rate cloud Apex, which is our monitoring and visualization platform. And what it does is that it actually monitors and analyzes your overall health of your distributed system. And I'll actually jump into the demo as well quickly. We have a video demo, and I'll quickly talk about different features of it. But just a quick point before we jump into the demo. One of the major goals when you were developing cloud Apex was that it should be simple enough and easy enough so that the network operations team can start maintaining and operating your cloud from the get go. Now, this is, I mean, we talked to a lot of customers. And one of the common feedbacks that we got was that how do I pull in my operations team? Because we are mostly talking with cloud architects. And their major concern is that how do I pull in my operations team? And how do I enable them to actually operate the cloud and not constantly talk to us for any basics operations and maintenance of the cloud? So that was a major goal, that you can enable your operations team, anyone who can actually jump into your cloud and figure out what's going on. Secondly, we talked about multiple different layers within the cloud. So there are a lot of different layers when you are actually going about troubleshooting. There is a physical layer, then there is a virtual layer. And even if the problem is very simple, like your two VMs are not unable to communicate to each other, even at that point, I mean, you have to traverse all the different layers trying to solve that issue. You cannot just talk about your physical layer and leave the virtual layer aside. So for instance, if it's a basic problem, like my two workloads are unable to communicate to each other, are they apart from a virtual perspective? Are they apart of the same tenant? Are they apart of the same layer two construct? Are they part of the same layer three construct? From a physical perspective, are they living inside the same physical host? Are they part of the same rack? Are they trying to talk across racks? So a lot of these questions that are there where you need to figure out, you need to provide a complete correlation between your physical resources and your virtual resources so that you can quickly figure out what's going on from that perspective. So let me just quickly jump into the demo that we have. So there are a lot of different highlights. I'll talk about each of these highlights as we go through the demo. So when we actually log into the Cloud Apics, this is the first interactive dashboard that you get on the top left-hand side. On the top left-hand side is your virtual view. So you have the tenants and your workloads, which are defined on the top. And then on the bottom, you have your physical view. So all the physical components are racked up in racks. On the right-hand side is the Details panel. So the Details panel actually is deflective of whatever happens on the left-hand side. So if you choose either of your tenants, the Details panel on the right-hand side gets activated accordingly. So Affinity-based UI is where we actually provide the correlation between your physical resources and your virtual resources. For instance, right now, what we did was that we selected a particular tenant at the top in your virtual world, and it quickly provides you the correlation that how many on the right-hand side provides the details at how many virtual machines does it have, how many physical servers does it have, what are the details around the tenants. And then on the physical side, you can quickly see that the workloads are living across how many different physical servers. You can scroll over it, quickly see, and figure out what's the correlation between your physical and virtual resources. And similarly, you can do the same from your physical hardware in a similar manner. So for instance, right now, if you select a physical box, you can quickly see that what are this particular physical box has almost 25 workloads, which are distributed across much different tenants, and you have your virtual different tenants, and then you have your event logs, which are accordingly associated with that particular physical box. So it provides a correlation quickly. Another feature is the CloudWide Search. So you can do CloudWide Search based on IP address schemes or MAC address or names for all the key attributes within your entire cloud data center. So you can either search for virtual domains or tenants. You can either search for workload names or you can search for physical hardware boxes as well. So from a troubleshooting perspective, like we talked before, that you have these two layers. You have your physical layer and you have your virtual layer. So how do you go about troubleshooting in both layers? So for instance, right now, what we are doing is we have just selected a physical box on the left hand side and on the right hand side, once on the Details panel, you can check all the different traffic stats in each of these. So you can quickly figure out what are the different traffic stats between each physical box? And you can also get much more granularity from a fact that this physical box right now is hosting almost like 8 to 10 workloads. So if you want to go much more granular and see that what are the traffic stats for each workload which is being hosted on that particular physical box, you can also do that using the same resource profiling view. So for instance, right now, you select these different workloads. And if you select either of these workloads, it will pull in on the Details panel. It will show you all the details related to that particular workload. So we selected any one workload on top of this. And if you drop down the traffic stats menu, you see the same real-time statistics of that workload which is hosted on this physical host. So moving on to the next feature, I'll jump on to the next feature so that we have a bunch of features to cover. So Heatmap is a way to actually provide a metric-based static system for your key attributes, either your tenants or your workloads or your physical servers. So right now, we create some metrics for your tenants. Based on those metrics, we can then go back to the resource view and then map them according to the metric that we just created. And once you map those according to the metrics you just created in one interactive dashboard, you can quickly see that it changes the colors according to the gradient that you just selected in the previous screen. You can set up the settings for Heatmaps based on either your tenants or your virtual machines or workloads or container-based workloads or physical servers. And based on these metrics, then you can go back to the resource view to look around and point and map the data according to the metrics that you just created. So what we did with Heatmap was providing the metrics per each attribute. Now, the next step is there are certain use cases where you want to group your end points, where you want to provide some grouping of your workloads. So that we can do using the resource tagging option. In a resource tag option, you can actually group your attributes based on security groups or type of tenants or a different type of the server characteristics. So right now, we are creating a metric for first the tenant. The second metric that we are creating are for a particular security group endpoint for your workloads. And then after providing certain values for each threshold that you want to set for this metric, we'll go on and create the same metric for the physical servers as well. So in physical servers, you can provide the metric based on the server role, so whether it's acting as a control plane for you, whether it's acting as a compute layer, or is it the gateway to the external world. And once you actually set those metrics, you can go back to the resource view and then set up your heat map, set up your resource view based on the metrics that you just selected. So for instance, right now, in one interactive dashboard, you can clearly see that based on the metrics that you just created, you have the ability to see the different gradients, which of the workloads are crossing those metrics, which of the workloads are having less traffic than the ones that you set. So in one interactive dashboard, you can quickly figure out that. Similarly, if you set the heat map based on the workloads traffic that you just said, here is the workloads view as well. So let me quickly jump into another view of dynamic security realization. So this is a new view that we created from a Cloud Epic's perspective. This actually shows all the different security group or security flows per tenant within your cloud. So for instance, you can choose whichever tenant that you have, and it would quickly show you the different security view of your particular tenant. From the resource view, you can select your tenant and go right click on it and go to the tenants as well. So right now, you see multiple different lines inside your security view. The red color shows the rejected flow, and the white and gray color shows the connected flows, and the difference in color shows the short or long-lived flows. So this actually quickly shows you that how quickly you can quickly figure out what is the current model of your each tenant. And this would obviously look different at different stages of your cloud. Perhaps at the start of your infrastructure, you have a model where there are a lot of red lines because the flows are not created continuously. And as we move along, you will see that the red line start to disappear because you have created those flows, and most of the flows are already set up individually. So very quickly, each of these bigger arcs defines a security group inside that tenant. And then individually, you can also scroll over to find out information on these individual endpoints as well. And similarly, on the right-hand side, right-hand side gives you a lot of information on all the logs. So you can filter and search the logs based on IP addresses or specific source and destination max on specific protocols, these kind of stuff. And the last part of this demo is just the self-organization of your overall cloud for troubleshooting purposes. And we briefly touched upon this during an earlier site on the heat map as well. So I think the time is always over. So just to end it on a note that the basic idea around Cloud Apex was to create a monitoring and operational platform so that in one interactive dashboard, your operation team should be able to figure out and monitor and analyze your cloud and quickly figure out what's going on if there is any issue in the cloud. OK, thank you very much.