eHeadache-Free
Cloud Networking

So welcome everybody to This Headache-Free Cloud Networking Webinar with myself, Malcolm Booden, and David Klebanov of Alkira. And I don’t know who knows us and who doesn’t, so with that in mind we’ve got a very quick intro. The chances are you probably know one or both of us if you’ve seen us advertised on LinkedIn. So I wouldn’t dwell on this but Malcolm Booden, and I’m based in Edinburgh, Scotland as you can probably tell from the accent, or that’s if you can understand me. I’ve been in IT for about 15 years, since about 2000 – well, more than that now. Since about 2003. And worked in multiple different roles at enterprise customers and anything from construction, to pharmaceuticals, and network integrators, internet service providers, outsourcing organizations etc.

I’m also the founder of MNB Networks, at our consultancy, which we deal with different customers on vendor agnostic solutions, predominantly Cisco. But we pretty much deal with anything that our customers require across landline security wireless data center technology. And we’ve got a big focus on wide area networking, at the moment, and I’m CCDE-certified, which I obtained in 2017. David.

All right. Great. Well, thank you very much, Malcolm, for having me here. So my name is David Klebanov, and I’m from Alkira I’m located in San Jose, California. I’ve been in the networking industry for I’d say over 20 years starting from the late nineties. Worked in different companies. I was in enterprise IT. I worked for vendors. I’ve gone through several startups and doing several roles of consultancy, network engineering, system engineering. Then did a couple of interesting things from the marketing standpoint, from technical marketing, from product marketing, and touched quite a few technologies in those 20-plus years, from campuses, data centers – not necessarily just the networking side of things. So I’ve worked on things like unified communications, IT telephony, back in the days.

I’ve done SD-WAN. I was part of the Viptela, which was acquired by Cisco back in 2017, and became Cisco SD-WAN. So I was running technical marketing for Viptela. That was that was a pretty interesting experience of how we transformed the entire basically wide area network – the enterprise wide area network space – with software-defined networking approach to that. And now we’re doing cloud. And I guess, today, Malcolm and I we’re going to talk quite a bit about the cloud, and that’s what Alkira is about. So I’ll give it give it back to Malcolm for a few more things and then we’ll kick it off specifically on the cloud and Alkira.

Yeah. And just before I do that, we’ll cover a little bit about that at the end, but if you’re wondering how a guy from Scotland partnered up with someone from San Jose, MNB Networks are partnering with Alkira, which is probably obvious – but we are an official partner. So Alkira is fairly new to the marketplace, although it’s been developed over the last couple of years or so. But David will give more information on that. So we’re one of the one of the first partners in the door, which we’re proud to be.

Yeah. That’s a good point that you’re bringing up, Malcolm. I’m very excited to have – we are very excited to have you guys on board with us, and basically drive thought leadership and adoption of the clouds in your territory and globally.

Brilliant. OK, so to move on to the agenda. If there’s anything – just before we go any further – just let us know if there’s any issues with the sound or anything breaks up. Don’t be afraid to send a message in the chat and we’ll try to address it, but we should be OK.

So the agenda for the session is we want to kind of take you on a journey as to what we’re seeing people do in the cloud space, specifically to do with networking and multi-cloud and – Yeah, so cloud networking and connecting to a single cloud and then evolving into a multi-cloud. So we’ll talk about some of the considerations for cloud connectivity, and then moving to multi-cloud connectivity. And then David will talk about Alkira and some of the solution details and benefits, and where it fits into the overall journey, and which headaches it can potentially address for you.

So if we start with this slide. And what I want to do here is, you know, most people, if you’re on this call, you’ve probably had some sort of exposure to connecting to the cloud. And there’s a perception – not from everybody – but there is a perception that what you need to do in order to connect to the cloud is get a free tier account from AWS as your GCP, deploy some VNs or some test VMs or maybe even just one application, which is a production application. So I’ve worked with customers who have, for example, put their ERP system and only their ERP system in one AWS data center, and that’s worked fine for them. However, they also use G suite as their directory services, and they have that. So they have the potential there – maybe not right now – but they have the potential, there, for a multi-cloud type environment, OK.

So but let’s just dial it back and we say, what do you need to do to deploy cloud? You register for your account, you deploy some VMs or something in the cloud, and you set up an [unintelligible 00:06:45] VPN over the internet to your gateway, on AWS, or whatever. Then you shift some data, and you start using the cloud. And that is the perception of a lot of people that I’ve had conversations with. And that’s all there is to it, right? But the answer to that is kind of like yes and no. So it depends, like any network design, and you’re never going to get a straight answer because every customer is going to have different requirements and things.

So if we look at some of the challenges certainly that I’ve seen – and these are only a small snapshot of them. So some of the things that I’ve seen as a consultant over the last few years are things like shadow IT. So an example of that would be I worked on it was actually an IoT-based project where – I won’t go into the details – but there was an in-house research team of an organization I was working with, and they developed this Raspberry Pi-based storage solution, which batch-stored images and then sent them up to AWS. They tested it for three months, and then came to IT and said, “We’ve been working with AWS. We’ve got this solution. It’s plugged into the network and the research labs, and now we want to put it into production.” Things like that. And you could argue about what with network access control, but they basically they’ve plugged it into a VLAN and a switch port which has been enabled and has [unintelligible 00:08:25] access on the network.

But they then wanted to roll that out to 300 sites across the world. So shadow IT can start off as good intentions with somebody with a company credit card and connecting into AWS, or whatever, and it can grow arms and legs. So the IT departments have to push back on that and say, look, before we can start rolling out global document and transfer solutions across 300 sites – Or another one that I actually seen was somebody had done a POC of I think it was a hand dryer or a toilet roll dispenser, and they connected it to the guest wi-fi network through the facilities management, and then said, “Now we want to connect this to the corporate network.” And the wireless network wasn’t geared up for that. There was not adequate security around that, and things like that. So that’s where the shadow IT comes in. And that’s a very basic example. I’ve provided an internet cloud, but there’s obviously – there’s options for direct connects. And so direct interconnects with Google, AWS and Azure with an express route connectivity offering. So the internet might be all right, but you might want something a bit more, well, it may be thought of as reliable. So basically an MPLS BGP-based connection and a co-location space or something like that, just to get that comfort that you’re not going over the internet.

And so large traffic loads – that that kind of speaks for itself. This is a big one. And we’ll see when David moves into his presentation, where Alkira really comes into its own on this side of things. So even with documenting a single VPC connection to AWS, that can even – I’ve worked on designs where there’s been a lot to just documenting that in a low-level design, for example. You’re thinking about different settings and configuration for the VPN, the route, and you use BGP, versus static route, and how do you feel over multiple internet connections to a single gateway and things like that. So manageability and documentation and with the, you know, without a standardized approach, you’re probably going to be fighting a lot of fires. That’s certainly what I’ve seen in the past.

Traffic flows, again, it’s kind of like large traffic loads. Know your traffic flows is probably the number one rule of network design. So understanding which availability zones and which cloud data centers you’re actually in, and how they talk to your private or your co-location space. And then onwards to your land. And No. 6 is the compliance and data center selection. So when you’re actually selecting a cloud data center, for example, there might be some compliance issues around which countries you’re allowed to use and which ones you’re not. So if you need to keep data in a certain country, for example. Securing the cloud infrastructure. The challenge with this, again, I’ll not say too much about that because it’s covered later on. But, for example, different data centers in different regions or different countries potentially managed by different teams could, even with the best intentions of having a you know a unified security policy globally, for your cloud infrastructure, if you’ve got all those differentiators in place, you’re probably not going to be as perfect or as good as it could be with a unified solution.

And then one of the main reasons we’re here to talk about, today, is how do you manage the security, the connectivity of the two key pillars that we need to manage between different clouds. So I’m just going to quickly walk through this slide. And it’s a story as to – I’ve kind of explained some of it already – but a typical scenario. Or it’s just an example. So this is not what every single customer does. But the white cloud and the red cloud at the bottom are basically your wide area network and your internet breakout, probably within your data center. But just think of it as a you know high level diagram for the moment.

So our company says right we want to connect to cloud instance one. So let’s just say for the purposes of this discussion that’s AWS. And somebody does the research and they say, “OK, let’s get our direct connect from specific. So they identify an AWS direct connect partner, go through that process, get connected, happy days. They now say right now we want actually want an internet backup VPN type connection to the VPC. OK, now we’ve got stuff coming in and out of our cloud, so we should probably put that in it, anyway, some sort of firewall to protect the infrastructure as a service which is provided in cloud instance one. So if we evolve a little bit further, and six or twelve months later and somebody says, wait, there’s something that we want to do in Azure. Just do what we’ve done with AWS and we’ll get a direct connect because that seemed to work pretty well.

So they get the direct connect, find a partner to provide that direct connect potentially a separate partner to help them with it. I don’t know. Depends who specializes in what. They get that set up and they say, all right, just so that we’ve got our common support model, we want an internet-based connection into that cloud. Right? But that particular partner uses firewall vendor, too. So we have the same security policy, potentially, but potentially – and again, that’s just an example of where you could end up if you don’t have a clear strategy. Cloud instance three comes along and we say, right, we want to connect to that. What do we do? We’ll just get a direct connect. Sorry, you’re gonna have to wait three months for that. So just now we’ll put an internet connection in, and we’ll get your VPN-based connectivity up. We’ll put your firewall in, which this is our preferred. And then once we manage to get the Telco connectivity in from the partner, we’ll then add the direct connect or the direct interconnect into Google.

So you can see how this looks like a very simple diagram at face value, but we’re only really just scratching the surface, here. But we’ve got multiple different environments, and if you if you think about the fact that these steps could be all mixed up, and you could have things happening at different times. And then once it’s all in a nice and pretty in place and looks like it does on the screen, you’ve then got to manage it. So how do you manage it? And this is this is just a very high level snapshot.

So if you look at the dashed lines here um like so if you if you think about like let’s say we need to get to these analytics platforms which are spread of core across public cloud one two and three um we’ve got multiple different ways to actually reach those depending on we you know you we see you up here at the top we might have some sites which are on traditional IPsec VPNs that require cloud access, we might have a some IOT field devices, which connect directly to the cloud. We might have IOT or tablets or something which have VPN clients on them. So if you think of agriculture, for example, if a farmer is out in the middle of a field and doing whatever it is he’s doing and he needs to update something to send it back to the systems, then you might need a VPN client that can provide that connectivity to send the data back to the cloud.

So we could then potentially have – this is not an SD-
WAN session, but if you if you think about where the industry is going with SD-WAN, we might also have multiple transports. So if you if you look at the portal Transport 1 MPLS, that might be for one connectivity, and if you’re going for like a hybrid approach, you’ll see that some of the stuff breaks out over transport to the internet. So without dwelling on that, you know, the key points here, in this particular diagram, the result of this topology translating to traffic flows is that in this particular example we’ve got six different clouds, if you like, so three transports and three public clouds. And effectively multiple different ways to get to those public clouds.

We might also have multiple wan site types, as well, so we have dual MPLS hybrid, internet only, Julian internet – the list goes on and on and on. So, you know, these are all things that we need to consider, as well. And devices communicating directly to the cloud from the field, mentioned the traffic flows. And this is a big one. That there’s no – If you if you go with this type of multi-cloud deployment, there’s no real way that I know of, anyway, to centrally manage that in a good way. To understand the traffic flows and manage the equipment, and so on and so on. Lots of these things will be covered by David.

And so where do we want to get to strategically? I’m just going to highlight a few things here. So we’ve still got the cloud Instance 1, 2 and 3 at the top, so our objectives from that perspective are still the same. But you see the single unified multi-cloud network, and we’ve still got the remote sites. Whoops, I didn’t mean to do that. We’ve still got the remote sites down here and they might connect to the data center or come in via the internet or whatever. But the one of the main things I wanted to highlight here was that in the previous slide – two previous slides ago – the firewalls were all different, and in this slide we’ve got – they’re all orange for a reason. And that is really to signify the fact that the security policy would be consistent throughout the single unified multi-cloud network, and that’s a big part of what Alkira brings to the table. So that really wraps up my part, and I’m going to hand over to David to present.

As I was listening to you, it’s pretty amazing how things that you are describing as the challenges that you are seeing in your in your sort of professional services work and working with customers, it’s pretty amazing how there’s so many synergies between the things that you’re saying and the things that we are seeing, as far as accessing the cloud. And you spent quite some time talking about accessing the cloud. But there is also a tremendous amount of challenges that are going for communication inside the single cloud and across multiple clouds, especially when you start layering things like services on top of just connectivity, and monitoring and centralized management that you mentioned. So all of these are just bullseye points that we are also seeing.

So let me take you through – there’s a bit of a lag, here. All right, let me take you through a couple of interesting things. First, I’ll kick it off with just a couple of words about Alkira, if you guys have not been introduced to Alkira, before. So we’ve been funded by three companies. Three major venture capital companies, within the Silicon Valley – Sequoia, Kleiner Perkins and GV, which is formerly known as Google Ventures. We started operating around may of 2018, so we’re about two years old. Our team is built of networking and cloud and security professionals that are coming from different walks of life. Some of them came from the vendor community, some of them came from the cloud service providers, some of them had consultancy backgrounds. So very strong very strong expertise. In fact, if you check us out on the website and you check out who our leadership team is, you’ll see that we have the same leadership team that we had back in the teledays. And you know that our Viptela run has ended with Cisco acquisition and the sort of the birth of the SD-WAN market, and now the Cisco SD-WAN solution. So there’s a pedigree of folks that are working at Alkira is something unique in the industry.

We started working with customers right away. Because the reason we started the company was so we can solve customer problems. So right there, even in 2018, when the company was just founded, we started working with early customers, and had great customer traction. We launched the company, formally. Went out of stealth mode about three months ago or so. It was mid-April. That’s when we kind of exposed to the rest of the world what exactly we’re doing. And what we’re doing is nothing short of reinventing the network for the cloud. And I’m going to walk you through a couple of interesting things – what this reinvention really means and why reinvention is needed. Because, to Malcolm’s point, earlier, it’s not very apparent. We sometimes approach customers and customers have this sort of notion that, “Yeah, that’s not a big deal. I’m just going to do it myself.” And some have done, and some have succeeded. But many have started and failed, only to find themselves in kind of the messy situation that Malcolm was describing with the complexities of cloud networking, multi-cloud networking, connectivity from on-premise sites into the into the cloud, integrations of security, management stacks. So a whole lot of things that go in there that aren’t quite as simple as they would appear to somebody who is just kind of getting their feet wet. So it’s important to understand why this reinvention had to happen and what are the real kind of challenges behind that.

One thing that I wanted all of you to realize is that, when you look at this public clouds – and we’ve been talking about the three major ones – the AWS, Microsoft Azure and Google Compute, the GCP. But also we shouldn’t forget about the SAS offerings. Office 365 is obviously a very popular one, but we also have other ones that people are doing, such as Salesforce, Box, Dropbox. Even some unified collaboration tools, which are very popular these days because of the craziness that we’re all going through, such as Zoom, WebEx, all of these collaboration tools. They’re all cloud offerings.

But if we look specifically at AWS, Azure and GCP, and you think about kind of three categories of folks that are consumers for this cloud services, these are primarily – If you look on the left, it’s a cloud architect, application developers. These are the ones who are transitioning from the data center deployments into the cloud development to get the efficiencies that are associated with going to the cloud. And these are the very known things. We don’t even have to spend a lot of time to capture those. Because it’s very obvious to everybody that when you go to the cloud from your on-premise data center, you get certain advantages, right?

You get the advantages of agile deployment you get an advantage of having these services, such as compute and storage being brought to you on demand whenever you need them. You need them, they’re up there. You can easily spin them up. You don’t need them; you could retire them. And that also leads to the as a service concept. You don’t have to do them manually. You don’t have to go and provision servers, just like you did in the traditional data centers. You go to AWS, Azure and GCP console, and you just request them. I just want a VM and you get a VM. I want that much storage for it, and you get that much storage for it. I want these interface cards. That’s great. You get these interface cards. I want this to connect to this network, and you get connected to that network, locally, there. So these are all excellent attributes that the cloud compute teams, and application teams have been able to leverage since AWS came out what in like mid-2000’s, right? So this has been really game changer for this for these teams to go and leverage those clouds with those attributes of agility, on demand availability, as a service, and of course more resources. I can easily scale it up and down.

So once this these transitions have occurred, the obvious question became, well, what about networking? What about security? I mean, these are the very fundamental blocks of this cloud adoption. And Malcolm talked about that. There is this shadow IT, but you don’t want to do that, right? You don’t just take your credit card and go and just buy some VPCs Vnet off of these cloud providers, and just leverage internet front doors, and have this application developers and cloud architects that are more of an on the compute side to actually go and own that network and security foundational stack. Because they have no strong expertise in that. So that’s when the networking guys are brought on board.

But if you look at what the networking guys can do with the same promise of the cloud, the world is not as bright for the networking folks. And I’m going to talk a little bit more about that in in the subsequent slides. But if you just realize what it takes for a network administrator, a network engineer, a network architect, to connect those corporate networks into the cloud, or to provide connectivity across regions of the cloud, or go multi-cloud, it’s basically plagued with a whole lot of challenges that the compute and the application guys are not facing. Because these clouds were built primarily for their consumption, and they were not built with an enterprise network and insecurity mind. So things that require really deep expertise in understanding the cloud, which again comes as sort of like a second nature to the compute/storage/cloud architects and application developers, when they move to the cloud – because they’ve been to that journey for a decade and a half. But it completely surprises the networking guys that are typically not that versed in the principles of networking in the cloud, that are quite different from the traditional principles that all of us have seen in the on-premise deployments and on-premise data centers.

So the expertise provide a very significant gap. Once you go past that, you’re facing with some restrictive cloud limits that are not something that you are aware of when you’re stepping into this. Because who would have known that clouds don’t support something as basic as dynamic routing, right? That’s interesting. That’s a foundational element of networking, since forever. Since decades ago, right? So how can that be that my cloud network cannot have this dynamic routing done? OK, that’s interesting. From security standpoint, how is it possible that the integration of my stateful security services, such as Next Generation firewalls, is not as easy as I could have done this if I were doing this in the data center. How do I engineer my traffic flows like that? So all of these things become extremely challenging from the network and security standpoint, and the visibility blind spots that exist there, and the provisioning for a peak. Because you don’t know how much capacity the application teams are going to request. So I need to over provision everything. And when you hear “over provision,” it’s of course overpaid. So all of these things are extremely challenging.

So what did the networking community sort of do about that? So there’s a couple of things that networking folks have done to try and solve the mystery. And there’s basically three major things that we’ve been seeing in the industry, as far as how the networking teams have been approaching. so one – and Malcolm mentioned at length – is the concept of co-location, which is great. It’s a dedicated interconnections from the on-premise environments through the collocation facilities into one or multiple clouds. But when you’re looking at how the firewall services are integrated in there, how cloud-to-cloud communication occurs, does it have to – can it go inside the cloud? Well, guess not. Not really. Because if I go cloud to cloud or region to region, I may need to go and backhaul through my co-location facility. so co-location provide a very efficient high-speed onboarding into the cloud, but they really provide a sub-optimal service from the standpoint of how do I go across clouds in a more efficient way and how do I make sure that all of that is done in a sort of a fast provisioned way? Because this this interconnector are not that easy to spin up. These co-location providers really take their sweet time to deliver the circuits to you.

Now, the second one is a cloud transit, which is extremely popular. And these cloud transits exist in different flavors. There’s a traditional cloud native cloud transits, such as the transit VPCs and transit V-nets, which basically kind of landfall your corporate network into the cloud and allow you to more easily go across clouds, more streamline access from the corporate WAN. Some of those could be as simple as VPN tunnels. Some of them could be as interesting as SD-WAN connection. So SD-WAN kind of falls into that middle bucket, as well. And these are again good solutions> But operating in a cloud-native cloud transit is something that again comes with the penalty of lack of expertise. If I provision this cloud transit, I need to kind of understand how the clouds operate because I’m now resident – my network is now resident within the cloud. My corporate network is now having this landfall within the cloud. So I need to understand this cloud and networking concept that I didn’t sort of have to deal with, before, and once I go into these concepts of course the limits emerge right behind that.

And the third approach we’re seeing is some automation tools, right? So I get it that maybe doing a cloud transit is interesting and more efficient than doing co-locations, but I don’t know – like I mentioned, I don’t have the expertise. So maybe I should go and get an orchestration tool, which is an interesting approach. This orchestration tool – some of them are in existence and they could be an adequate solution for some customers. But keep in mind is that automated complexity doesn’t mean that you’re solving this complexity. You just make it sort of obfuscated, abstracted, but it doesn’t mean the complexity goes away. So when you go and you need to troubleshoot things and you need to understand what exactly is happening under the hood, you still have to deal with those traditional concepts that exist within the clouds, because the orchestration tools only take care of certain elements and primarily provisioning elements of this cloud and multi-cloud connectivity.

They also can do some troubleshooting and visibility elements. But, again, the underlying concepts of the cloud are not really changing. So some interesting things that we are seeing from the cloud adoption standpoint. And where we’re really driving is you need to change your thinking. You, as a as somebody who is a network engineer, or is a network architect, who is thinking about that I need to expand my network into the cloud. I need to accommodate this cross-cloud connectivity. I need to make things as agile as my cloud architect and cloud admins and application developers are. I want to be in the same category and be agile to my business. So how do I do that? I need to really change my thinking.

And the key principle here is that stop thinking in terms of primitives and start thinking in terms of principles. And if you really kind of think about that, the networks of today – and these are traditional networks, but also cloud networks – they’re all based on this networking primitives that you have to understand in order to be able to build this network, right? I need to understand what you know how the routing exactly works in order for me to build a global route network I need to understand if I’m looking at the cloud native things, I need to understand how these transit VPCs or transit gateways operate because these are the tools that have been made available to me, as a network administrator, by the cloud providers. so if they give me these tools, then of course I need to understand how they work and all the intricate details of how they work in order for me to build this network to and across clouds. As opposed to looking at what the compute guys are doing and the cloud computing and the cloud storage guys and application developers that really have moved past these primitives into the principles and intent-based approach, where they just say, “I want this,” and it’s just delivered to them without understanding what exactly does it take to deliver this under the hood. What exactly is the type of a network interface card used. What is the bios settings on the server, right? These things are irrelevant, from the infrastructure standpoint, to those folks, because they’ve been abstracted. They’ve been turned into principles.

So we really need to change the thinking from primitives to principles when it comes to networking. And that’s exactly what Alkira comes to do. Alkira turns this networking concept to be compatible with this application migrations to the cloud. So if the applications move to the cloud, the network has to be operating in such a way that it has to be built for the cloud and it has to behave like the cloud. So it’s a pretty interesting concept behind this transition from primitives to principles.

So how do we do that? So I’m going to quickly walk you through a couple of interesting things that are the attributes of an Alkira solution. So at the heart of our solution is what we call an Alkira cloud services exchange. So what is this cloud services exchange? We think about this as this unified multi-cloud network, which Malcolm has mentioned. This unification of this networking tier, right? And it’s delivered to you as a service. So now you can see that this cloud attributes that I talked about, this primitives that have to go to principles, they now start emerging into the networking, as well. So the as a service element is something which is very critical for the delivery of this global unified network that goes to the clouds, inside the same cloud, across multiple clouds. So it’s this ubiquitous sort of network plane, data plane, control plane, management plane, from the networking standpoint, that really stretches across this entire sort of network universe.

Now, what this cloud services exchange consists of is what we call an Alkira cloud exchange points or CXPs. Sometimes you can hear us mention this as a CXP. So what cloud exchange points are, they are your mini-datacenters. These mini-datacenters, from the standpoint of delivering network and network services, have now been uplifted into the cloud. So think about them as mini-datacenters, or a points of presence, that exist within this Alkira’s cloud services exchange. And what you do as a customer is you connect to those cloud exchange points, those CXPs, from your locations – and this could be in on-premise locations, this could be your remote sites, your campuses, your datacenters, or even your on-premise SD-WAN fabric.

And you also connect your cloud resources. This could be your AWS VPCs and Microsoft Azure V-nets and GCP VPCs. And they could reside in one region or multiple regions. And they could reside in single cloud or multiple cloud, obviously AWS GCP and Microsoft Azure. So the internet exit points for your internet and SAS applications, that we mentioned, such as Office 365, those are also connected into those cloud exchange points. So you’ve now built this unified sort of foundational platform for all of your connectivity needs between anything on-prem and the cloud, and anything within the cloud.

Now this cloud services exchange, or those cloud exchange points within cloud services exchange, they’re not just for connectivity needs. They have far greater use for your network as, in a sense that I mentioned, think about this as mini-datacenters. What did I mean by the mini data centers? They host your services, your network services. They give you the full visibility elements your network. So there’s quite a lot of elements that are baked into this cloud exchange points that become your single point of connecting to the cloud and across multiple clouds. And some of these key things that exists within this cloud services exchange is the way that you provision things through a design canvas. Again, one of those attributes that’s going from primitives to principles is an ability to have an intuitive design canvas when you can design your network and just express your intent and just click a button and say make it so for me. Just like the compute on the compute side, you say, “I request this virtual machine. Make it so.” I don’t care about what network card you use. I don’t care about what memory DMs you use. I just want this much memory, this much disk space. I want this to be connected to this network. I want this operating system on it. All these attributes that are the principles, the same things is now delivered to the networking and security through this design canvas.

Now, I mentioned services quite a few times, but we operate a services marketplace. This marketplace allows you to choose services that otherwise would have been residing in your datacenter. But since your applications are moving to the cloud, so are the services. So we wanted to give you this concept of market or services, network services marketplace, where you can choose a service that you want to onboard into this Alkira cloud services exchange, and now use that service for your communication needs across multiple things that are connected into this cloud network that that you now have built. And these are many times we’re seeing security services, such as firewalls. So take your firewall with you on the journey into the cloud.

Now the intent-based policies allow you to really easily steer the traffic to those files – and I’m going to touch on that, shortly. And again, some interesting things around segmentation and pervasive encryption. These are the very inherent abilities that are required for operating a network and are now delivered to you as part of this cloud services exchange, which is as a service offering. Now the data operations have to be there. Because, frankly, you can’t really operate a network, be that a network of a small size, moderate size or a very large enterprise network size. We have customers from all walks of life. You can’t really have a network that doesn’t have the appropriate day 2 operation tools for visibility, troubleshooting, management, monitoring. So these things become very critical and are inherent within this service

And lastly, we’re seeing a very interesting trend as far as the chargeback is concerned. So we’re all used to the fact that the IT teams are usually picking up the check for deploying and infrastructure services. But no more. When you’re talking about the cloud, you have this ability in the cloud for cloud compute resources and cloud storage resources, to really know who is consuming those resources and perform a chargeback to those individual departments. So everybody can participate in this sort of financial responsibility for consuming the services. Now we’re taking this concept and extending this into networking. No more is IT responsible for all the charges that result from the utilization of those clouds, from networking standpoint, from traffic standpoint, from you know resourcing standpoint. And this becomes a shared responsibility of all of the participants in that solution, and these are different departments that are leveraging this unified, multi-cloud network in order to connect their cloud instances together or connect from on-premise sites into those cloud instances. So that becomes a very important element of how to share this financial responsibility. so these are very interesting points for how this multi-cloud network really is delivered as a service and it becomes very compatible to the way that things are done in the cloud.

Now if you look at a specific a customer design scenario — and I know that Malcolm kind of walked through that, so I’m gonna go fairly quick on this one. And we would love to kind of entertain more detailed discussions in your particular case, but what we’re seeing is that many of the traditional customer designs really start with some sort of a network fabric. And many times we’re seeing this these days is an SD-WAN fabrics are playing a very significant role in sort of connecting on-premise resources to the clouds. But that could also be an MPLS, as well. And we’re seeing things such as remote user access into that. We’re seeing cloud connectivity through secure web gateways. We are seeing clouds that are onboarded through private direct connects and express routes. We’re seeing cloud connectivity that is delivered through the cloud transit that I mentioned earlier. We’re seeing an internet being sent through the datacenter, and through the data center DMZ. We’re seeing business partners that are connected to the datacenter, and different sort of security requirements that are accommodated through the firewalls that are provisioned in different parts of the network.

So we’re seeing a lot of kind of designs that look similar to this, from both connectivity on-premise connectivity to the cloud, and connectivity across clouds. Now, what we’re also seeing is that these designs are also flawed with things that that customers are sort of fighting in order to remediate. And we’re looking at disparate security domains, such as Malcolm mentioned. Is that it’s not a single point of enforcing that security policy. These policies are enforced in multiple ways and for the accessing the SAS resources and internet resources, these are many times secure web gateway or security internet gateways that provide that service. Now when you look at the access into the public clouds and across public clouds, this is the proliferation of security inspection points in form of firewalls that are resident in cloud transit or call locations or data centers. Again, maybe from a single vendor, maybe from multiple vendors. So this proliferation of security inspection points definitely becomes a challenge. production deployments so but all of these they have – we’re seeing some you know very strong commonalities.

Now what happens inside the cloud itself is again a deep expertise that are required, that I mentioned earlier, and the limitations that are coming right after that for deploying this cloud and security services. So all of these things are the challenges that we’re seeing customers are really facing and battling with when they are embarking on this cloud adoption journey. And that’s exactly the reason that we have such a such a strong interest in Alkira Solution, because it really is the mechanism to unify all of this networking and security concepts into a single, as-a-service delivered platform, with this attribute – this cloud attributes that are really compatible with the way that clouds work, and compatible with this notion of applications moving into the cloud.

Now, these customers, when they when they consider an Alkira solution or consider a solution, they’re looking for this various design principles that they want to follow, such as building this enterprise-grade network, providing interoperability with their existing environment, be that SD-WAN or MPLS. Providing optimal access into the cloud or providing hybrid connectivity between the on-premise environment and the cloud environment. Providing segmented access to partners and secure DMZs in the cloud. So all of these they become a very interesting points that the customers are really kind of set their priorities on in order to search for a solution. And again I can’t stress more is that this concept of as-a-service, which is really applicable to this cloud transitions, comes very clearly in all of this design priorities that customers are developing.

And customers are in different phases of where they are in this sort of phases of design. Some of them are doing some just exploratory, some of them are doing proof of concepts, some of them are doing production deployments. But all of these we’re seeing some very strong commonalities across all of them in order to sort of accommodate this design priorities. And, again, the delivery as-a-service becomes a very key attribute to that.

So how do customers really do that? And that’s like echoing some of the things that I mentioned earlier. So building a global network foundation for connecting to and across multiple clouds becomes very important. Think about this as establishing your foundational of global network with this high-speed, low-latency backbone, which is delivered through those cloud exchange points – the Alkira cloud exchange points that I mentioned earlier – that are distributed around the world in any location that a customer really wishes to be present in.

And then they are the resources that are cloud resources are connected into those respected cloud exchange points. And this could be a single cloud or multi-cloud resources, single account or multi multi-account scalability elements of do I want this much capacity or that much capacity? All of those elements, they’re all accommodated within this cloud connectivity. And the similar way happens to the on-premise environments, such as a connectivity from the remote sites, remote users, co-locations, SD-WAN fabrics, datacenters, the partners. All of these, they’re all a collection of these on-premise resources that are also connecting to their respective cloud exchange points in order to be part of this one cohesive customer network. And frankly, the same attributes that apply to the cloud, apply to the on-premise sites, as well, as far as an automated connectivity, as far as an ability to support an existing site scalability that can be tuned up and down. So all of these all of this become also very important not only for the cloud workloads, but also for the on-premise workloads.

Now we know that security plays a very key role. And I’m giving here an example of a security deployment. In this case, I’m using Palo Alto network’s firewalls. I mentioned earlier is that we in Alkira Solution, your firewall basically goes for the ride with you when you are going into the cloud and that firewall gets uplifted into the cloud and offered as a service from within the Alkira cloud services exchange. We really want to maintain the same enterprise-grade stateful security services that were provided by these firewalls when they were deployed on-prem. We want to provide the same granular sort of stateful security when they’re moved into the clouds. So our solution very nicely interoperates with the concepts of segmentation and the concept of security zones that are present in the firewalls. In this case we’re using Palo Alto networks firewalls, but really present in in any firewall vendor. So really kind of transforming this security from being an on-premise centric, into an environment where you can have the same level of policy, the same security zones, that are applicable both for your on-premise resources – because we realize that you’re not going to the cloud in one day. So this is applicable to your on-premise resources, but also equally applicable to your cloud resources. So the same security policy can be applied now through both. And, again, the reason for it is that now you have this unified approach to not only networking but also to security.

I mentioned that it’s not just about AWS, Azure and GCP. We’re also looking at SAS and internet applications. And really designing that secure access to those applications is something that we are seeing customers are doing more and more, especially when these internet exit points get disaggregated and distributed from just being anchored onto the datacenter to being available at the remote sites, IPsec-connected remote sites, MPLS connected remote sites, SD-WAN-connected remote sites. So all of that notion of getting into the internet, into the SAS as fast as possible, yet maintaining this single cohesive security domain, is something that we’re seeing very clearly. And, again, with the Alkira solution, when these sites are onboarded into the these cloud exchange points, they basically immediately get this connectivity, this fast shortcut connectivity into the cloud, but also, to my earlier point, the same security enforcement policy that was applicable inside the datacenter, that is applicable inside the cloud, now is also applicable to the SAS and internet access from those remote offices.

And when we’re talking about security, as you can see, as your cloud deployments grow and your needs for this capacity of this firewalls grow, there’s a need for the solution to accommodate this scale in needs. And what we are doing, we are in fact doing this auto scaling to make sure that this firewall capacity remains available to you any time that an application requires any kind of policy is steering the traffic to the firewalls and that and that traffic becomes excessive or more than it was accounted for. And if you recall one of the challenges that I mentioned earlier is the over provisioning. So rather than over provisioning, auto scaling becomes a very critical element to that. But when you’re talking about firewalls, such as stateful devices, there’s really interesting elements in there that we won’t have time to talk about today, of course. But how do you maintain this bi-directionality or symmetry of that traffic across this scalable firewalls? So it’s a very interesting thing. But think about this as this zero touch auto scaling that’s basically just auto scales your cloud firewall capacity.

And when you’re looking at this firewall capacity that stretches across multiple locations – because what I talked about earlier was basically kind of a single location. So when you look at that from these multiple locations you really want to make sure that this auto scaling is augmented by inability to perform this really intelligent traffic steering that crosses multiple cloud exchange points because your resources are distributed, and they’re not just located in one region, they’re not just anchored on a single cloud exchange point. But when they’re anchored on multiple cloud exchange points, in single or multiple clouds, how do you really get this higher capacity for your cloud security right? so these are very interesting elements.

Lastly, and most importantly, is the operational and visibility elements to have a single interface, to see this infrastructure help and application help and network help and network help, and to be able to troubleshoot, all of these are very important. And, again, through the cloud services exchange portal that you get access to, when you become a customer, you really get this thing completely laid out. And that’s why we have customers who care about that, such as an enterprise customer – maybe a little bit less about that such as small and medium-sized customers they just want the functionality and maybe less interested in these deep insights. But, again, the enterprise customers that we’re working with, they have they have the need for both.

So I’m not sure we have any time for question and answers. So I’ll give it back to you. Malcolm, I apologize for running a little bit overtime. I guess I underestimated how long it’s going to take to explain this concept. But I’ll give it back to you.

Sure, no problem. Thanks very much for that, David. We did have a few questions that came in – like four or five. So I’m not sure if we can cover them all but we’ll take a note of them and contact people offline, if that’s okay with you.

Yeah. I think I think that makes sense, yes.

The first couple and no preference. They’re literally the first couple that came in and they seem quite straightforward, hopefully, that you can answer. So which locations does Alkira service available in?

Right. So as I mentioned, we are a global service. We are present in any global location that a customer has a need to connect into this global network. There’s really no limits to where our points of presence are these cloud exchange points.

And then just to just to round off the questions, I’ll take a note of the other ones. So the only other one was: When using SD-WAN, can SD-WAN segmentation be carried into Alkira?

That’s an excellent question. Because I know that coming from Viptela, we know that segmentation was a very key element that our customers wanted to have. Sometimes this was the major driver why they wanted to go to SD-WAN beyond kind of the points that you have articulated early on, such as multiple transports and things like that. So, yes, the segmentation is very important in SD-WAN. And what we are doing, is because SD-WAN can be easily onboarded in an automated way into the Alkira cloud services exchange, we are also extending the segmentation principles of SD-WAN into the cloud. So if you have a sort of an SD-WAN site that has a presence of two segments, and you want to continue the segmentation all the way into the cloud, I think that it’s very important for you to make sure that that segmentation is not lost when the traffic hits the cloud. And what we’re doing, we’re picking up this traffic into our exchange and we are keeping the segmentation all the way into the cloud resources and often between those multiple cloud resources. So if you have an HR and Finance, an HR user is going to see HR resources, a finance user is going to see finance resources, and the segmentation is carried across both SD-WAN and the cloud services exchange.

Brilliant. OK. And that slide has just been up for a minute. So as we explained at the start, so MNB Networks are working with Alkira in partnership. So to round off, you can find out more about both of the organizations at the websites. And if you’ve got any – I will contact the people who have sent a question in in the chat, but if you have any other questions or want to take the conversation forward, and also see a demo of Alkira, then we’ll work in partnership with Alkira to sort that out and arrange it, and we can talk more about specific requirements. Hopefully, you’ll have seen that there’s a plethora of different considerations and every customer network’s going to be different. So there’s a lot of complexity that needs to be talked about in order to ascertain whether it’s a good solution or not for you. Nothing else for me. Thanks very much, David, for joining us and thanks everybody. There’s people from basically every corner of the globe who have joined us tonight, so thanks for giving us your time and all the best and enjoy your evening.

Thank you very much, Malcolm. Thank you very much, everybody, and see you next time.