1-Click
Multi-Cloud
Network Services

All right. Hello, and welcome to this Alkira webinar. My name is David Klebanov. I lead product marketing for Alkira. Today with me we have our co-presenter, Misbah Rehman, who leads our technical marketing. Misbah, you want to take a second and introduce yourself?

Sure, thanks David. Super excited to be a part of this webinar. So yes, I lead the technical marketing at Alkira and will be helping you with this network services webinar.

Right. Awesome. The topic of our webinar today is to really talk about the multi-cloud in general and specifically about the network services and the network services architecture, which becomes a very acute point when organizations are embarking on the cloud adoption journey.Now, here’s the agenda for our webinar today. We’re going to spend maybe a minute to give you a little bit of an introduction on Alkira and then dive into this with different network services architectures, the ones that predate the cloud, the other ones where the cloud happens, and we have the traditional networks services architectures. We’re going to spend some time talking about that. Of course, most of the time we’re going to focus on the network services architectures for the cloud that we bring to the market as Alkira.

Now, a couple of housekeeping items: You are more than welcome to ask questions. We’ll try to get to as many questions as we can. We’ll carve out some time at the end of this webinar to take some questions from the ones that you’ve been asking. We’ll be monitoring the Q&A window.

With that said, let me introduce in a couple of words about Alkira, for those of you who are not familiar with us. Alkira was founded in May of 2018, so we’re about two years old. We got very quickly funded, within six weeks or so by Sequoia, Kleiner Perkins, and GV, which is formerly known as Google Ventures. Total funding is around $30 million.

We immediately started working with our customers, so we had, obviously, a lot of early interest in what we are doing. Our customers started coming in even late 2018, and obviously throughout the entire 2019. Then recently, last month, we launched the company out there, and that happened on April 15th, 2020. That’s where our website went live, and of course you’re more than welcome to go and visit our website at www.alkira.com.

Our mission is, really, to reinvent the networking for the cloud era. That’s our mantra. That’s what we’re after. We want to take a hard look at networking and network services and see how those change and morph in this cloud world. Obviously, there’s quite a few things that need to be done differently in order for this cloud adoption to be successful.

So, as I mentioned in the beginning, let’s spend a couple of minutes talking about different cloud networks services architectures for the cloud. For the organizations that adopt the cloud and treat the cloud as its own isolated entity. So, we say here, it’s predating the cloud, but in fact the cloud has been with us for a decade and a half. It’s not really predating the cloud, but rather treating the cloud as an outsider entity to the organizational IT control.

This is the environment where applications live in a cloud. However, they’re not under the IT control. Now, most of the applications that are under IT control and under IT infrastructure reside in the data centers or potentially in colocation facilities. Now, the connectivity to those places is done through a corporate network. There’s nothing new in here. For applications that are Internet bound or Internet based, such as SaaS applications, the access to those is done through the data center.

Many times, the access to the applications dictates the positioning of the network services. When the applications reside in a data center, obviously the network services are also positioned within the data center. Here we can talk about a slew of the different network services. Obviously, some of the most popular ones are firewalls, IPS, IDS, load balancers, DNS, DHCP, IPAM services.

For applications residing in the data center, those services are oftentimes provisioned in the data center. For applications in the colocations, the colocations become the place where those network services live or, at least, maybe the subset of those network services. For applications that reside on the Internet, such as SaaS applications, of course because the access to those applications is done through the data center, so the services that reside in a data center, they also serve those applications. This is really a traditional, old-fashioned view into this.

Now, if we look at how these network services architectures have transitioned and have morphed in order to accommodate the cloud, we can really talk about three different buckets of solutions. I’ll walk you through each of them, and we’re going to have a separate slide for each one, so this is just a sample of these three different approaches to adopting the cloud connectivity and also inserting those network services.

Now, on the left, you can see colocations. It’s a very popular option. It basically means an organization establishes a footprint for connectivity and for network services within different colocation facilities around the world, wherever the need exists. A private interconnections oftentimes used – those are the direct connects, the express route, the dedicated interconnect based if you’re using AWS, Azure, or GCP. The services are really resident there, and the connectivity to the colocations and to the clouds through the colocations is done through a corporate network.

The second one is cloud transits. That’s where the architectures have morphed in order to accommodate these cloud transitions and as applications move to the cloud, so are the network services. Now, the network services that are moving to the cloud have to be resident somewhere, because they are in the cloud; but where are they in the cloud? That introduces those cloud transit architectures, and those cloud transits are per cloud, and there can be more than one per cloud.

Those are the cloud transits that host those network services. Again, the connectivity to those cloud transits is oftentimes done through the corporate network and different means of connectivity. We’re going to touch upon that in a few minutes. Of course, the third approach is an as-a-service approach, which is the approach of Alkira and we’re going to spend a significant amount of time talking about that, so we can just leave it at that. But it’s an approach where you are consuming the cloud connectivity and the cloud network services as-a-service.

Let’s take a slightly different look into the colocation option. Again, this is the situation where the applications have moved to the public clouds. Collocations are the anchor points to connect to those public clouds. Again, private means of connectivity oftentimes are used, direct connects, express route, dedicated interconnect based on which cloud you are connecting to.

The services are resident within those colocations, and that’s for the reason that services have to be in a place where the cloud is being accessed and because the cloud is being accessed through the colocations. So that’s the place where the services are. Many colocations, many places to put your services in. For those environments that have adopted this direct internet access for accessing SaaS applications, that forces the services to be also resident at those remote locations.

Those could be firewalls, IPS, IDS appliances, whatever it may be. They can be in physical form, they can be virtual form, but it’s a footprint of the network services within those remote sites if the local internet exit points are provisioned to those.

Now, what are the challenges that people are encountering with this approach? We really can talk about three different buckets of challenges. The first one is complexity. As you can see, applications are residing in the cloud. The services are residing out of the cloud, because they are residing in the colocation facilities. So that creates a situation where the application traffic, the network traffic, that requires this network services treatment, has to be swinging in and out of the cloud in order to be processed within these colocations by these network services.

You can think about this approach as a cloud on a stick. Imagine one AWS VPC needs to talk to another AWS VPC, or something a little bit more elaborate, one AWS VPC has to talk to one Microsoft Azure VNET. Insertion of a firewall into that communication requires the traffic to be drawn out of the cloud into the colocation, through those direct interconnects, and processed by these network services in order to go back into the cloud to reach its destination.

That’s what we mean by this, cloud on a stick. You can imagine the level of inefficiencies that you will be incurring when you adopt an approach like that.

Now of course, in order for these network services and the network in general to operate in this environment, there’s a pretty complicated set of routing that needs to happen in order to accommodate that. It has to do with routing table virtualizations with VRFs and multiple zones of the firewall or multiple IPS appliances in order to accommodate that, so quite a lot of complexity that has to do with those services residing outside of the cloud.

Again, because outside of the cloud, they’re not leveraging those cloud efficiencies as far as the provisioning cycles. That brings us to the second point of how long it takes to provision them, the cost of investing capital investments in the colocation provisioning, in the provisioning of those dedicated interconnect, in provisioning and deploying those network services that many times are physical appliances within the colo, and your provisioning services in the branch locations that expands it even further. All of that carries a high cost mark.

Now, let’s look at the second approach of the cloud transit, where we can see organizations are improving on the traditional architectures by saying the applications that have moved into the cloud are also forcing the move of the network services into the cloud, which obviously brings a level of efficiency, because now the services can be co-resident with the applications within the cloud.

Sounds interesting, right? Where are those services going to be hosted? There are multiple places they can be hosted. They can be hosted in individual VPCs and vNets, but many times we are seeing those services being placed in cloud transits, and those can be transit VPCs, transit vNets, or they could be attached to the TGW in case of AWS. There’s a couple of points to consider in here. Again, we’re talking about three main ones that we want to bring up, the symmetry, performance, and operations and cost.

Sending the traffic through those network services that are now located within the cloud, within multiple cloud transits, potentially the multiple cloud transits within the same cloud, introduces a great amount of complexity, especially when that steering of the traffic to those services is done based on routing controls. Some organizations have worked around that by employing an active standby approach or by leveraging network address translation in order to force the symmetric traffic flow through those services, though all of those significantly complicate the environment.

Now further, if you are considering multiple cloud transits – which is often the case, because clouds are distributed by nature – those multiple cloud transits that are hosting those network services, the traffic that goes through those cloud transits and those network services has to be daisy chained, so to speak, in order to keep the symmetry. Imagine cloud transit one that has a firewall, cloud transit two that has a firewall. Now I need to traverse both cloud transits in order to reach from source to destination.

You can imagine that, in order to keep the symmetry, using just route-based approaches, I have to traverse that firewall twice; once in cloud transit A, and once in cloud transit B. There’s a level of inefficiency that has to do with symmetry. Those services, many times, are leveraged in cloud-native constructs for traffic steering, and that’s when the cloud-native limitations come up as far as, for example, tunneling performance or things like that.

The performance becomes another complicated set of attributes that need to be catered to in addition to symmetry. Ofcourse, all of that boils down to complicated operations and the cost that is being spent to stand up these architectures. They’re all heterogeneous in nature, because each cloud is different. Once you’ve deployed a solution in a single cloud, and you want to expand to maybe a different region of the same cloud, or even go further to a different cloud, all of that becomes a compounding effect and turns operation and cost into a big item.

As you can see, cloud really introduces challenges to this traditional network services architecture, which is where we understand that something needs to be done differently. That’s when we enter the world of Alkira. I’ll spend a couple of minutes talking about this slide, and then I’m going to hand it over to Misbah to carry on the conversation about some of the details.

What we have created at Alkira is, we’ve created this notion of what we call a cloud services exchange, an Alkira Cloud Services Exchange™, which is this unified multi-cloud network. Think about this as a multi-cloud network service that is delivered to you as-a-service and incorporates the elements of intelligent network connectivity, on-demand traffic steering for network services, and full visibility in governance.

There’s a lot of elements that we have embedded within the cloud services exchange that make this as-a-service approach very appealing. As a customer, what you connect to the cloud services exchange is your remote sites, your remote users, potentially your SD-WAN environments if that’s what you have. At the same time, you connect your public clouds, public cloud instances, different regions and instances in different regions of the same cloud, your internet and SaaS exit points.

Everything that is in your inventory, as far as what requires connectivity and requires network services, all of that is connected to the Alkira Cloud Services Exchange through what we call Alkira Cloud Exchange Points™, which are virtual multi-cloud points of presence that are globally distributed and allow you really quick and easy onboarding into your entire multi-cloud environment.

There’s a couple of attributes that you can see on top and that are important as part of our solution. First and foremost is a very intuitive digital design canvas that allows you to express your intent and then – with a single press of a button, with a single click of a mouse, with a single API call – to implement and to provision that intent onto the global virtual infrastructure that we have provided for you and that you can consume as-a-service.

I mentioned connectivity. We obviously, on top of connectivity, provide you this advanced network services marketplace where you can choose the services that you want to deploy out of this marketplace, and we will make sure that those services are deployed, instantiated, monitored, managed, and that traffic is steered to them based on policies. So, all of that is part of this as-a-service approach.

Things like end-to-end segmentation are inherently built within the solution. So is the day-2 operations for this as-a-service approach. Ultimately, we want to make sure that you have full transparency as far as how the service is being charged for and also have an ability to perform a chargeback, which is extremely important for the IT organizations not to become basically the bearer of the entire expense for multi-cloud adoption. We provide very meaningful tools in order for the chargeback to occur and for IT organizations to become more financially viable.

Having said that, I think that gaves you a little bit of an introduction as far as where we’ve been, where we are. I want to transition to Misbah. Misbah, take us through some of those things that I’ve mentioned and talk more in detail about the network services architectures for this cloud solution.

Sure. Thanks, David. Let me see if I’ve got the control, and I can move the slides. Yes. In the next few slides, I’m going to double-click into three different aspects of the solution. First of all, we’ll talk about Alkira’s network services security architecture, the challenges posed by the current network security architecture when it comes to the cloud, and how we are helping our customers to consolidate and standardize this network security architecture for both on-prem and cloud networks.If you look at it from a cloud perspective, the options that we have in terms of securing our workloads inside the cloud are pretty much setting up security groups, network ACL, that basically protects our workloads that are running inside the vNets and the VPCs. When it comes to on-prem, we can have our firewall appliances with stateful firewall inspection, and then we can also offer advanced security services on those.

Basically, the net-net of this is that you will end up having two different types of security architecture. One that is working inside the cloud, and one that is working inside the on-prem. To help things out here, what firewall vendors did, they came up with their VM appliances for the cloud.

So now you can actually spin up the firewall services as a VM inside any of these clouds, which definitely help the enterprises in the sense that now the enterprises can have the same – it actually help the enterprises in some way, because now with the VM appliances, you can at least have the same type of device that is running both on-prem or in the cloud.

Plus, you can manage it with the same management tools and the systems. However, the problem is all these VM appliances that are running inside the cloud are still running on top of the cloud infrastructure. You can spin up those VM appliances, but from the connectivity perspective, from the cloud-limitation perspective, you still have to build your architecture that still needs to be limited because of all the stuff that the cloud-native solution, or the cloud-native construct, has to offer.

To prove my point, for instance, in terms of the cloud architecture that is based on these firewalls VMs, you end up needing some kind of transit vNet, VPC, or TGW, or any other kind of transit connectivity options that the cloud has to offer. You have to steer your traffic using a cloud-native construct through these firewalls and back, and then basically when it comes to expanding this network across different regions, the network itself becomes so complex that it becomes impossible to manage an operation.

At the same time, you do not get the same level of feature and functionality that you get on-prem. For example, a concept as basic as segmentation, which we are all used to doing on the on-prem side of things, we are used to putting our stuff into so that we can securely isolate the traffic from the get-go. A concept like segmentation is not possible in the cloud. The problem is that if you want to achieve segmentation, your architecture will become super complex. At the same time, if you want to extend multiple circuits into the cloud for each segment, it becomes too costly.

So, what enterprise did is, they end up having one flat cloud network. Then on the infrastructure side, on the on-prem side of things, they’ll have some kind of route leaking into each segment to make sure that they are maintaining the segmentation, at least on the on-prem of the things.

The thing is, even though you have the same devices running in both the networks from an on-prem and a cloud perspective, from an architecture perspective, the feature and functionality perspective, you still have two different types of network running one on-prem and one in cloud. What we did at Alkira, we were working on integrating these network security services. We wanted to make sure that we fully understand the requirements from a security perspective.

Those security requirements need to flow through from on-prem into the cloud. Whatever you get on-prem, you should be able to get the same functionality in the cloud as well. Plus, at the same time, we do not want to offer these kinds of services compromising the simplicity, because simplicity and ease of use is in the DNA of the solution. So, everything that we are going to provide should come with simplicity and ease of use.

So, what we have done here, as you see on the slide itself, there is this whole lot of segments. Anything that we basically add into our portal or into the Alkira network, the building block from the get-go is the segment. Any connector, whether it’s on-prem, whether it’s cloud, whether you are terminating an internet connection – or extranet, for that matter – becomes part of the segment.

You can create multiple segments, and they will be isolated from the get-go, and the way that the segment will flow through inside the service is done automatically, out of the box. From a user perspective, in order to maintain the segmentation end to end, you do not have to do anything. You just have to define your intent that these are my workload that are part of this vertical segment. As part of the service, they become a part of that segment, and that segment flows end to end.

What we have also heard from the customers is that segment is not enough in terms of grouping different services together. Inside the segment, this can be all part of this one enterprise segment, but we can have different types of connectivity. For instance, I can terminate my on-prem sites. I can terminate my cloud workloads. I can terminate the internet or extranet or some partner network.

The point is that there is another level of granularity that was needed in order to simplify the policy. On the left side, for instance, what you see, the intranet, which is the on-prem sites. On the right side is the cloud side. This basically gave rise to another concept that we have inside the Alkira service offering, the group and the zone stuff. Inside the segment, you have the ability to define groups and the zones and you can define your policies based on your business outcomes.

For instance, traffic coming in from the on-prem, I want a particular policy that needs to be applied when it talks to the internet. When it talks to the cloud, I want a completely different policy. So, I can group these similar constructs into a group and apply those policies based on the rules that I want to define and what type of traffic I want to allow. Basically, this is all done through our Alkira intent-based policy framework. The point is, it’s as simple as defining your intent: What do you want? And with a simple, single line of policy, it is applied across the board, across your entire network.

We can actually steer the traffic. We can also do it based on the application matching. It’s pretty flexible, anything that you can be able to define to steer your traffic. The outcome of it is that we provide you an enterprise-grade security architecture. We can integrate these security services for cloud and on-prem alike. It’s done with a very simplistic approach to our Alkira intent-based policy framework.

So Misbah, you’re basically saying that the segmentation is a great tool to separate things around, but what we’re providing here is something I can think about as micro-segmentation that allows me to further sub-divide those segments into security zones in order to facilitate firewall security policy.

Exactly. You can go as granular, based on your business outcomes.All right, so the next use case that I want to cover here is the secure SaaS and internet access. Before I cover this use case, I want to just revert back to the history slide that David was talking about where we can have an architecture, where we can have a data center as an exit point. We can implement firewall policies there to actually access the internet in a secure fashion.

Actually, that architecture worked really well and was one of the more popular architectures when it comes to the enterprise network. But as SaaS starts to become a reality, those architectures won’t work anymore for the enterprises, because the point is the building block of the SaaS architecture is to be more distributed. They want these SaaS workloads to be closer to the user. They build the SDN architecture where they want to basically make sure that the user gets to it as soon as possible, as soon as it hits the internet.

Now, looking at that architecture and marrying it with the Alkira architecture, they fit very well with each other, because what you have been seeing, us talking about this architecture of CXPs, is, these CXPs are globally distributed. They are globally distributed across all the different regions, and the point is that we want the users, the cloud workloads, the data center, to be terminated with the closest CXP.

Again, as I was talking about the SaaS architecture, it exactly aligns with that. What we do here is, we provide the ability for the users to terminate closest to the closest CXP, provide that enterprise-grade security and firewall services at that CXP, and provide you the exit point into the SaaS application for optimized SaaS exit.

So, with the simplistic architecture of an intent-based policy, you can simply terminate any of your workloads to the CXP and basically make sure that you get the optimized secure exit into the SaaS application. Everything at the end is segmented where you can have different policies for each internet exit or SaaS exit for different types of segment, basically done at the segment and based on the intent-based policies.

Basically, the net-net is optimal SaaS performance with the uncompromised security that you are getting here.

You know what I really like about this, Misbah, if you can go back one slide, what I really like about this is this balanced approach to where those security services are being inserted.You don’t want to put them all in a data center. We talked about how that’s very inefficient. We certainly may not want to put them in every single remote location, because that becomes operationally challenging and expensive. I think what we offer is a balanced approach of having those services reside in this as-a-service delivered solution. I think that strikes a tone with many customers. Is that what you’re seeing with customers you’re interacting with?

Yes, definitely. I think, in addition to what you are talking about, is the point that I made. If you look at the SaaS architecture, based on the SDN and everything, this is exactly the architecture for this next era, the cloud era, that we are talking about.Our stuff, from a security perspective, as we are talking about that you do not need to backhaul the traffic, you do not need to have security at each remote site and all that, you have these points closest to the user. You are still getting the enterprise-grade security plus, at the same time, you are not compromised on the performance when it comes to SaaS.

The next one I want to talk about is zero-touch autoscaling. Again, if you look at the cloud, the way the cloud changed the game is, it lets you configure the resources when and where you need it. You do not have to statically set up your infrastructure. You do not have to statically build your data center or compute resources. You just come and consume it in a pay-as-you-go fashion, and just use it when and where you wanted it.

This is great from a compute and storage perspective and other application perspective, but if you double-click into this from an infrastructure perspective, for the most part, network is still static. If I want to build my network infrastructure, I want to build connectivity into different regions of the cloud. I still have to build my network for peak usage, because I cannot just set up that – okay, I’m setting it up for my average use, and when the peak hits, my network will start to fall apart.

Everything is very dynamic. You can consume the resources in a pay-as-you-go fashion. When it comes to infrastructure, things were pretty static. From an Alkira perspective, since we are built in the cloud, we wanted to make sure that, from an infrastructure perspective, we follow the same principle as well and we deliver that services for infrastructure as well in an as-a-service.

So what we are doing here is, from a network services perspective, we give the ability to our customers where, at the time of provisioning, they can define the minimum and the maximum number of resources that they need and this is, again, purely based on the utilization, based on their planning, the way that they have seen the pattern in their network: This is the minimum usage I see at a particular time. This is the max, this is the average that I see.

Based on those numbers, simply at the time of provisioning, they can define those numbers. Once they define those numbers, what we’ll do is, we’ll start off at the minimum number of resources that are needed. Then we will proactively and constantly monitor the traffic that is going through those services and basically on demand, making sure when we need it, we will spin up those resources automatically, make sure that your network does not fall apart.

You’re still getting an optimized, secure connectivity into the workflows, whether it’s going from sites to the internet, whether it’s going site to the cloud, or cloud to cloud. Now you have this optimized secure connectivity at the same time you are efficiently utilizing your cost as well, because in a static setup, if you’re building it for your peak utilization, you will end up having resources where you just have those resources up so that your network does not fall apart, and you are paying unnecessarily for those resources, considering most of the time you don’t need it.

So, in this case, this is again done out of the box, as a service construct, where you do not have to manage the life cycle complexity of these firewalls. These are all done automatically. When it comes to spinning up multiple firewalls, as network engineers, we all know that symmetry is a key and David, you also mentioned it in your earlier slide.

So here, from a symmetry perspective, we will make sure, again, out of the box, that whatever flow that is entering into the Alkira network, we will automatically detect which firewall it’s basically entered into the system and on the way out, we will make sure that it exit out from the same firewall.

What it does is, it basically makes sure that we do not have to do any workarounds like NAT that they were talking about in order to maintain symmetry. It is basically done on the actual source destination, and it’s done intelligently from the service.

The last slide that I’m going to cover is the multi-cloud network visibility. As we talked about network architecture, there are two disjoint architectures. The story is no different when it comes to operations and operational visibility as well. On the on-prem side of things, we are typically used to SNMP traps, network flow logs, basically punting to our monitoring tools. While on the cloud side, we have to depend on the cloud-native solution that somehow have integrated into the monitoring tools.

So again, the idea here is that you have two different solutions for visibility, for management, for operation. What we have heard from customers is that in the end, since they’re two disjoint solutions, you still end up having blind spots when the interconnectivity of these solutions or these two networks are involved.

So since we are doing this approach where we are connecting the two worlds seamlessly, the cloud world and the on-prem world, we wanted to make sure that we provide one unified way from a visibility perspective where we can provide pane of glass for the operations team to manage their entire infrastructure, not having to worry about that, for cloud, I have to have another two for on-prem.

This too, itself, inherently will give you the infrastructure. For instance, if there are on-prem devices, how are those physical devices connected into the network. We’ll be doing keepalives to those to make sure they are up and running. Similarly, on the cloud side of the things as well, we are going to monitor it. Again, basically present it to a single pane of glass.

We can also monitor the application usage through our network, so we can give you a snapshot where – how your applications are being consumed inside the network for on-prem and cloud, and then you can actually drill down into a particular region to see how a particular region is using a particular application. Then we can connect it to an individual flow level.

There is, again, a lot of granularity, a lot of ways that you can actually look at it, and it can basically help you in order to have a high-level snapshot to just look at it, how your network looks like, and how it’s being consumed. Then, for planning purposes, you can go drill down to an individual connector level to see if there’s a need to upgrade your bandwidth or anything inside your network.

Again, the rest of the stuff we talk about, we also show you the network utilization services and many more. The idea here is that, since this is the service offered, the seamless connectivity. In the same way, from a visibility perspective, we wanted to offer one tool, which is enterprise grade, which works well for both the on-prem and cloud, leaving no blind spots for you to manage. You will have the entire end-to-end visibility into your network.

So, with that, I’m going to hand it over to David to just walk us through the key takeaways and talk about the next steps. David, over to you.

All right, well thank you, Misbah. That was very insightful.A couple of key takeaways for things that we’ve been talking about for the last 40 minutes or so, things for you to remember, is one, quick provisioning. I mentioned that when I first introduced the Alkira Cloud Services Exchange. I did mention that everything we do is done on the intuitive design canvas and provisioned with a single click of the button, the single API call that really allows you to build that smarter network for the cloud.

We spent a lot of time today talking about security. That was the topic of our conversation as far as network services are concerned, and Firewall is one of the representative network services that we use for security, but of course we didn’t spend time talking about other network services. We mentioned the network services marketplace, which has more than just security services.

We’re talking about a whole slew of network services. For security purposes, we’re really talking here about replicating this enterprise-grade security that people are used to deploy in their on-prem environment and replicating this enterprise-grade security into the cloud and multi-cloud environments. The intelligence that comes with steering the traffic, which requires a level of symmetry and how that can be achieved in a global environment, be that in a single- or multi-cloud environment. The intelligence that Alkira solution has for this symmetric traffic steering. The high capacity that can be achieved through automatically scaling the network services.

We call this a zero-touch autoscaling. You set this in motion, and the autoscaling happens based on the capacity demands that your application exhibits in the cloud environment and, at the end, just like Misbah mentioned before this, the operational excellence that comes with the full visibility and governance that is included within the Alkira as-a-service offering for the cloud and multi-cloud environments.

At the end of the day, we started off with that. I guess we’ll repeat that again. Our mission statement is to reinvent the networking for the cloud era, and to be able to really help the enterprises, the organizations, to uplift their environments into the cloud in a way that is not compromising on the feature richness of connectivity and the feature richness of network services, and specifically the network architectures that we talked about today.

Now, Q&A: I know we ran a little bit over. I know there’s been questions coming in, so I think that what we’re going to do is, we’re going to address those questions individually with each one of you. We really appreciate the questions that have been flowing in. There’s quite a lot of them. We’ve been monitoring those. We’ll make sure to go back and follow up with you on anything that is of further interest.

As far as the next steps are concerned, we invite you all to visit our website at www.alkira.com, where you can learn more about our solution, where you can request a demo that you can test run and test drive the Alkira solution. If you’re ready to make the step into the multi-cloud networking with services visibility and governance, obviously we invite you to go and register for the Alkira service, very easily done on the alkira.com website.

Now, stay tuned for more. We are releasing a very exciting podcast that we have recorded with Packet Pushers. In that podcast you’ll be able to hear enterprise and cloud architects who are our customers that discuss their cloud needs and their cloud challenges and how they really leverage the power of Alkira in order to provide a solution for their connectivity and network services visibility needs.

It’s a pretty cool podcast. I invite everybody to access that and download that. I think it’s very valuable for a lot of you to see how our customers are realizing the value of what we’re bringing to market.

With that said, I want to thank everybody for attending. I want to thank my co-presenter, Misbah. Thank you very much for being part of that. We invite you to stay tuned and follow us more and join our future webinars. Thank you very much.