Good morning to those in Australia, and good evening to those in other parts of the world. Welcome to the investor briefing on Megaport Virtual Edge or MVE. Today, we have presenters located in Brisbane, Sydney, The UK, San Fran, and Austin, Texas. I'll just run through some housekeeping at the beginning and the agenda for the day and then hand over to Binnie. For those that have followed Megaport, in August 2020, we announced the upcoming upcoming release of MBE and collaboration with Cisco.
On the March 31, we announced the launch of MVE available in 11 metros with plans to extend it to 21 metros globally. Megaport and Cisco have also partnered to integrate Cisco SD WAN cloud interconnect with MVE, leveraging Megaport's 740 plus locations globally and 227 plus cloud on ramps. This was followed by a partnership with Fortinet, we have three more SD WAN providers in the works. Today, the agenda will involve John Bisardis, our VP of engineering, running through the history of SD WAN, the addressable market, and the major players. He will also consider some of the challenges faced by customers and the Megaport solution to reaching the cloud.
Matt Simpson, our VP of cloud, will address MBE pricing and some typical SD WAN use cases. James McElvanna, one of our leading solutions architects, will then run through a demonstration of connecting a customer to SD WAN via NVE. And finally, Rodney Foreman, our chief revenue officer, will address our go to market and sales motions. Today's session should run for about thirty minutes and will be followed by Q and A. Please send your questions to via email to investormegaport dot com, and these can be sent through at any time starting now.
We are recording this webinar and will make a re replay available on our website. I will now hand over to Megaport's CEO, Vincent English, to run through MBE in more detail.
Thank you, Steve. Good morning, everybody. Thanks for joining our presentation briefing this morning on MBE. First, Steve just run down through the agenda. The most important objective here is that we understand that there's been lots of questions from the community about MBE, so we wanted to tackle those here in this one form.
It's not a market update or a briefing. This is specifically a product overview and an update on MBE. To that end, we would just move to the evolution of MBE on the platform for Megaport. And just to recap, we started out in 2014, we're connecting data centers via our platform, Megaport, at the time connecting using ports and VXCs into public service public cloud providers and other MSPs. And the idea here, as we all know, is Elastic is to be allowed to spin up services, connecting at different speeds, different service points and having the flexibility for the customer, for the enterprise to connect to end services.
Over the over the over time, that evolved effectively to from the first of its kind for network as a service, where we were able to address a large global network connecting nearly today over 400 data centers physically connected then. We rolled out MCR, which is our cloud provider, which connectivity between different cloud providers. And and so we kept enhancing the platform. And as we announced earlier this year, moving towards a Megaport connected edge where we were allowed to we're extending our foot for our physical footprint that we've built, the network as a service and the global network that we've built by allowing capability to connect to other buildings outside of that footprint using Megaport Virtual Edge. In terms of the what is MBE, I would try to keep this, distill this down as succinctly as possible.
It's a hybrid network and compute service that hosts network function virtualization on Megaport's software defined network. As I've explained a couple of times before, what we are really doing here is we're layering over the existing physical network and other forms or other services that we can bring to the market. In this particular case, using MBE on the network element of it, we're allowing connections or point bridging to the pub from the public network or public Internet to connect to Megaports on demand platform. And to do that, we're connecting with the to get the compute side of it, we're hosting with software service like SD WAN providers. And some of them, as mentioned on the slide, Cisco, Fortinet, VMware and Versa.
These top four account for 48% of the SD WAN market. Now SD WAN is only one element of network function virtualization that we can roll out across the MVE platform. There are other ones, but today, we're focusing on SD WAN. And looking at the Megaport virtual edge overview on the diagram, you can see here, we are integrating connecting buildings, and the buildings can be branches in terminology used for SD WAN providers. The branches can be actually buildings, facilities, other locations where physical hardware or customers, CPs are.
They use the Internet connecting to an SD WAN provider to connect to an endpoint or branch to branch. In this particular case, we're using the Megaport platform through our portal, which is fully integrated, connecting endpoints such as branches using an SD WAN provider, using their public Internet to connect to MVE, which then connects into the nearest data center on our network, which then allows the customer to traverse our network to connect to a public service provider or, in fact, to another branch on the other side of the network. So it extends the reach of our platform. That's the first thing. So we're leveraging the platform.
We were the first ever to integrate fully with Cisco SD WAN as as the use case. It supports branch to branch connections, but more importantly, branch to cloud is the number one use case that we're seeing from customers today. We've built it using our own technology API built for future integrations and extension. It extends the enterprise network edge, And again, it allows to activate more demand network devices and it's completely end to end provisioning. Now I'm going to hand over for the next couple of slides just to go into a little bit more of a deep dive on what exactly SD WAN is and how does it work and what's the problem it solves and how does it complement what we do with MetaPort.
So John, would you like to take it on?
Thanks, Vinny. So a little bit about SD WAN and how Megaport ended up to where it is with MBE. You think could you go to the next slide, please? Yes. If you think about enterprise networks, today and in the past have been very heavily reliant on MPLS technology.
That's technology that has traditionally been delivered by the incumbent telco where the enterprise, you know, may purchase many services from that incumbent telco. They purchase these services with term commitments, which have fairly costly walk away clauses that can take a long time to set up. So when you bring on a new branch office, one of the first things you do is set up your network connectivity because that can take months to fulfill. And it works you know, it worked well for branch to data center con connectivity, but not so well for cloud connectivity. And as a result, what happened was many there are a few number of vendors started looking at alternatives to MPLS and came up with the terminology, technology called SD WAN.
This allowed enterprise customers to use their local Internet connection to move enterprise grade traffic over that connection. And in light, many of those connections were as good or better than the MPLS networks they were moving from. So Internet got very good over the over the years that the telcos have been delivering it and suddenly became good enough for enterprises to use it. So SD WAN allows an enterprise to use policies to control what traffic goes for those encrypted links. And you can determine whether a specific application, like for instance, a cloud application, can go over that encrypted SD WAN link or whether traffic like maybe YouTube goes over your traditional Internet, connection.
SD WAN also allowed customers to route traffic based on link quality. So you could determine whether you wanna use your DSL link or your LTE, your secondary LTE link based on the quality of those networks. Unfortunately, cloud is still a hard thing to do with the current SD WAN technology. It is complex for an enterprise to set that up in cloud. It's costly.
You know, the data charges associated with cloud can be quite costly. And you have to think about the applications you have in cloud and you set up these connections for each one of those app applications. The other bit is you see many, many enterprise applications moving to cloud. And as such, the current approach to SD WAN has been very complex for enterprises to engage in. What Megaport has done is we are taking center, the technology we've had in the data center, the concept of the VXC, the concept of cloud connectivity or data center to data center connectivity, and extending that out using that MPE edge.
So that SD WAN technology that is sitting in that branch office connect to that edge and provide the same platform that we offer to ports in the data center to SD WAN links that come for those branch offices. Additionally, what we've done is we've given our APIs to vendors and to our customers so that they can simplify that cloud onboarding. I mean, many of you have seen the time it takes for a customer to onboard in the cloud, and they can do it in just a matter of a few clicks. We wanted to extend that functionality to the SD WAN vendors as well. So we've done that using APIs to do that extension.
I'll go in that into one of those integrations in just a second. What we've also done is taken our backbone and delivering that to those SD WAN customers. So no longer do you have to use Internet connectivity over long reach distances to connect to other branches. You can now link to the MDE Edge that Megaport provides and traverse our enterprise class backbone to other locations that you may have connected to. So giving a dramatically different experience to those customers on how they get connectivity to branch to branch.
And that that dramatic difference is really about the quality of experience. But it's not good enough just to give that quality of experience. You have to help the customer get to that SD WAN edge as quickly as possible. And as part of that, we've deployed many locations across our platform to be close to that enterprise. And what I mean by close is latency close, the number of hops that you go over your Internet provider to get to us is reduced.
So we can an enterprise can get to that better quality experience quicker. And you can't do this without supporting a lot of the incumbent players in the SD WAN marketplace. And let's talk a little bit about that. And if you can move to the next slide, please. So what we've done is we've realized that we needed to go work with the leaders that enterprises are purchasing and making commitments to.
So one of that is we've gone and integrated to many of the SD WAN, leaders as part of the that you can see in the Gartner Magic Quadrant. So we've gone through and looked at their market share, looked at their presence and capabilities, and chosen some of those top vendors to do that integration with. And I think Vinnie went through and mentioned some of those Cisco, VMware, Fortinet, Versa, and eventually some others as well. What we've done by doing that is, first of all, many of our internal customers are very excited with that proposition so that they can take technology that they're already using, the Megaport technology, and other technology they're using, the SD WAN technology, and integrate them together in one network that they're very familiar with. And additionally, this offers us the ability to go to the tens of thousands of additional businesses that adopted these technology theaters as their choice for enterprise connectivity.
So that gives you a sense of the type of market that is available to Megaport. Could we go on to the next slide, please? One of those leaders is Cisco. And what we've done with Cisco is fairly unique in that we've done a very deep integration with them with a console that they call vManage. VManage orchestration console for all their SD WAN connections.
And from there, through that single pane of glass, that single management user interface, the customer can provision an NVE edge, that is that connection that is in all the regional metros that may be close to you, as well as provision the VXCs onto those cloud endpoints or even to other branch endpoints. So through that one experience, the customer can go and provision not only the technology that they're using today and the connections they're using today, but the whole Megaport platform connectivity to cloud, to other other data centers and other branches. Additionally, through that whole vManage console, they can implement traffic and policy controls to that one interface. And on top of that, we've taken a lot of the technology that they've used traditionally with MCR and allow them to do that cloud to cloud connectivity using their SD WAN management pane. That's a solution that we've delivered through Cisco today.
That technical integration is done. The next bit we're working on is to integrate with the Cisco price book. That means to have those MBE components available on Cisco's global price list and being able to have customers billed by one entity, that would be Cisco, and specifically sold by Cisco's SD WAN specialists across the globe. So not only a technical integration, but also a billing experience integration for that end user. And we believe a very compelling solution for enterprise customers.
Thank you. Now I'll hand it over to Matt.
Thanks, John. Hi, everyone. I'm gonna be walking you through a couple of real world use cases, for both a small and a large enterprise, and we'll also be outlining the revenue associated with those use cases. But before we do, I'm also gonna do a little bit of a recap on the MBE and the pricing and how it actually works and how it's built together just to give you a little bit of a an idea of the the revenue associated with that. So if we walk from left to right, you've got four different MBE, medium and large.
In the small, you have two CPU, which
is the
compute, and included in that is 500 meg of Internet transit. That's the Internet to access the MVE from your branch location. Medium is four CPU with one gig of transit, and then the large is eight CPU with five gig of transit. What's really important is with the small, medium, and large, it supports up to forty one hundred and five hundred IPSec VPN connections, which is essentially branch locations. So small can actually connect up to 40 branch locations.
And when I go through those use cases, you'll see which sort of NVE will suit depending on the number of branch locations an enterprise might have. As I mentioned earlier, we've bundled the transit in. So these prices for North America, Europe, Asia, and ANZ include the transit, and they are a little bit different because transit and the cost of transit is quite significantly different depending on the region. So in North America and Europe, it's quite reasonably priced. So $15.45, and then Asia, $21.40, and then ANZ, 2,670, which is in Australian dollars.
We've also just broken out the actual MBE price so that you can actually see the difference between the MBE and the transit price there. Now with the transit, it is a pure pass through. We don't mark up the transit, and we also don't provide commissions or discounts on the transit because it is a pass through cost. Now in terms of best practices, we associate at least two VXCs to the metro or or cloud when an MVU stood up. And when I go through those use cases, I will be providing a little bit more clarification around branch locations and endpoints versus the number of VXCs an enterprise may need in terms of connecting to some of their applications.
Next slide, please. So John and Vinny mentioned the the locations. There are 21, enabled today, and those 21 locations are, sitting on the similar infrastructure to MCR. However, our strategy on the rollout of NVE is to ensure that we get closest to the enterprise rather than closest to the cloud or the application. Because we've already enabled the cloud interconnect points, We now need to get closer to the enterprise, and we'll continue to roll roll out more locations by working very closely with our SD WAN partners that we've brought on board.
And we've already got phase two and phase three locations coming through over the next twelve months. Next slide, please. Okay. So the first use case, small enterprise. This enterprise has seven branch locations in Los Angeles.
And with that, they would only need a small MVE. Now that small MVE, of course, can house up to 40 branch locations. So as the small enterprise is building with Megaport, they can still utilize the small MBE and connect up to 40 branch locations. So in this use case, it's only seven. And then from the MVEs, so you go from left to right.
So up to seven branch locations doesn't mean that they need seven VXCs. They only need two VXCs. And those two VXCs are going to be primary and secondary to their cloud provider, whether it be an AWS or a Microsoft. And the VXCs are connecting locally in a cloud region, so within that same metro. So similar to how you've seen with our other products, up to one gig is $200, and up to 10 gig is $400.
So with that in mind, you've got $15.50 for the MVE, including the 500 megatransit, and the two VXCs at $200 comes at a total of $19.50. And these are, again, our retail rates. It's not taking into account partner commission Onto the second use case. This one's a really interesting one. This was a a an existing Megaport customer.
So what's really interesting is they they had mega ports already with us, but they were actually hairpinning their traffic back to Las Vegas and Reno, as you can see on the left hand side. So this is a Fortune 500 US company. They've got 1,100 branch locations all across The US, and they've got 40,000 employees. So those 40,000 employees across those 1,100 branches, have got to access some of their databases, some of their applications running on AWS and Microsoft, and they had private infrastructure in a colocation in Las Vegas and in Reno on the West Coast Of The US. So they had Megaports with us, and they were connecting those Megaports to their cloud or their applications, which is great.
They were using us. However, if you think about the spread of their branch locations and their employees, that latency was or the the traffic was going all the way back to Vegas and then going up to Microsoft. With the MVE, they can now connect those branch locations locally. So if you see on the right hand side, you can see they don't have any East Coast presence. So with MVE, they stood up those MVEs, and now those branch locations or those employees now can actually access the applications and the cloud on the East Coast.
So the MVE now connects up to the East Coast cloud region. And to give you a bit of an idea of the problem that they're solving, not only are they now accessing the East Coast, they're also reducing some of their latency. So by avoiding hairpinning to, like, for instance, to Dallas, their Florida sites can now reduce their latency to AWS by at least 50%. Miami drops from approximately eighty milliseconds to forty milliseconds. Orlando, all those branch locations drop from sixty nine to thirty thirty one milliseconds, and then Miami traffic travels is almost half.
So it's like Orlando is, like, 2,394 miles. Now with MBE, they're only connecting, and it's hitting a thousand miles from those branch locations. So we know that with this particular company, you know, with 1,100 branch locations, they'll need medium MVEs because those medium MVEs can can host or connect up to a 100 branch locations. And as you can see there, they've got VXCs to not only their ports to their private infrastructure, but VXCs and redundant VXCs to their cloud and applications. So if we look at the table to the right hand side, we've got four MBEs, which is one in Atlanta, Chicago, Toronto, and Seattle.
The VXCs to the ports to Vegas and Reno, and then they've got 16 VXCs to their ports and their cloud applications on East And West Coast. And the total monthly recurring revenue is just over $15,254 per month US dollars. And that is only just one customer, and we're looking at, of course, bringing on many, many more. And that is, I believe oh, no. Next slide.
What do customers actually get? So we wanna just make sure everyone's very clear on what Megaport provides and what our SD WAN partners are providing. So the customer, before they actually come to Megaport, will have an interconnect Internet connection from their branch location. That's through their provider. They'll have their SD WAN vendor selected.
So it's really important that we have all of the the rich ecosystem SD WAN providers out there as John mentioned. But they'll also already had purchased that router or that CPE equipment at the branch location. Megaport won't be responsible for that. And they'll also bring some sort of SD WAN license to use and run that SD WAN service on our compute. With Cisco, of course, it's integrated, so it's just one easier step.
But with the other vendors, they'll just enter that. And James will be showing that later on. So with Megaport, what are they getting what are they getting? They're getting a for DNS protected Internet connection at our edge, at our network edge, and they're getting that full Megaport ecosystem. Those MVEs will hold up to 24 VXCs, and that is, of course, separate to the branch location numbers that I mentioned earlier.
And then, of course, the MVE gets access or VXCs to any destination on the Megaport network. And that's it. I'll hand hand it over to James.
Hi, everyone. I'm I'm James McElvanna. I'm a solutions architect with Megaport. I'm gonna do a very quick demo today. Just jump into the portal.
My plan is to show you very briefly three things. One, how quickly customers can spin up a virtual edge. Two, demonstrate how the MBE exists in both the SD WAN vendor's platform and also in the Megaport portal. And then lastly, I wanna show how easy it is to build a connection from
the MBE to the cloud providers.
So first step here is I'll go to the normal Megaport portal that our customers use on a daily basis. I'm gonna select MBE. I'm gonna pick a location, Atlanta. From here, I've got to select the vendor. For the purposes this demonstration, I'm gonna go with Fortinet.
And you can see here that I've got a couple of different options. I'm gonna pick the small at this point, it's asking me for an application license.
So I have to go to
the Fortinet asset management page and download a Fortinet license. I've already done downloaded this, and then I will add it here. And then for security access purposes, I need an SSH key. You can see I'm getting the monthly charge down at the bottom. I'm gonna add MBE.
And in the per in the interest of time, while that's deploying, I'm gonna jump into the 40 manager, which is the management console for Fortinet. And you can see here, I've already added one earlier on this afternoon. For all intents and purposes, this is where the customers will manage this device, and it'll appear just like a norm a regular physical SD WAN hardware plants in the customer's management console. And so all the day to day operations are gonna be done here, you know, access lists, quality of service, intrusion detection, BGP. And this has got the same for Cisco and VMware.
And you can see I
can even go in and actually configure it from the console if I wanted. But just to jump back to the portal, I'm gonna show you that this is the another m v the MVA that I was just showing there. You can see that it's already got the Internet access included, There's the public IP addresses. There's the IP transit. We've got IP version six.
Also worth noting that this includes the DDoS protection. So similar to the way our customers are already creating cloud connections via Megaports, via Megaport cloud routers, it's the exact same process to add a connection to AWS. So I'm gonna go here, click on add connection. I wanna get a cloud connection, pick AWS. For speed,
I'm just gonna pick it.
Hosted fifth. And You can see here that literally within the space of a few minutes, I've been able to build an MBE and also then build a connection, a one gig private layer to high speed connection to AWS all, you know, within the space of a couple of minutes. And that's it from me.
Ronnie.
Alright. Thanks, James. That was a great demonstration. And, with a great product, you need an exceptional go to market so that we can sell it. So that's what I'm going to, take you through now.
We've put a lot of focus on putting the right team in place to support our selling motion. So we've, hired a dedicated team of sellers and solution architects to be trusted advisers to our our partners that are on the SD WAN side with Cisco, VMware, Fortinet, and and others soon. We are enabling, those salespeople and and have started the sales enablement process well before, GA and and continue to enable the sellers in the field, and providing them sales playbooks and other, collateral that I'll talk about in a moment so that, they are fully enabled to, sell our product across industry and, utilize, many of the use cases, some of which Matt took you through, so that they understand what the target customer looks like, what their value proposition is so that they can, execute, identify opportunities, and and go through the sales cycle as quickly as possible. We are targeting, indirect and, direct sales. So we're targeting the market using the SD WAN resellers, distributors, and service providers in an indirect or channel selling motion.
And then, also, we're supporting their direct sales teams targeting specific industries that fit the profile of the best, SD WAN, customer that can utilize and get value from MBE. We are on the Cisco global price list and also on the Cisco Commerce workspace. This is significant because this is how the Cisco seller sellers get paid and how their partners get paid and obtain benefits from Cisco. So it's important that we're on the price list and we're in CCW. If you go to the next slide, please.
So we have a blended go to market here with both leveraging the extensive network of partners, from Cisco, Fortinet, and VMware, and our direct sales teams both working in harmony, to attack the market and identify opportunities. We are, supporting those direct sellers with our solution architects. James is one of those, that you just met that is, supporting the direct sales teams. We are making sure that, Cisco, Fortinet and VMware partners are trained, enabled. They understand our solution and are, have the ability to identify opportunities to sell.
That includes their entire partner ecosystem, those resellers, MSPs, GSIs, and the, VADs, as well. We are already jointly selling Megaport and Cisco together, and we're conducting joint presentations together, demos, POCs, targeting, existing and potentially new customers, together, working together. And that joint selling is working very, very well so far. If you go to the next slide. We have a very good go to market plan, that I believe is well thought out and is being executed very well to date here, you know, fifty days or so into the GA of the MV product.
We have some very good marketing assets that the team is leveraging, to sell in the way of battle cards, demos, and we've got a excellent, marketing plan and a lot of marketing activities going on. We have integrated into the management consoles of, the SD WAN solutions, and customers can order, through, the SD WAN providers and through, Megaport, those panes of glass, working together. We have, field enablement, as I said, going on with, dedicated resources that are, training, both the channel partners and the direct sellers. And we continue to revise and improve our go to market jointly together with those SD WAN providers, making sure that we have a joint value prop, that we, have, sales playbooks, demos, that, apply across industry and attract, some of the largest, customers, existing customers we have and new customers. Matt showed you a few examples of those.
So I think we have a very thorough, go to market action plan in place and, the right selling motion to lever leverage both the direct and indirect sales channel, to win as many, opportunities as we possibly can in the market. Next. I believe that's the last slide. So I'll turn it over to you, Steve. We can, start the q and a.
Thank you, Rodney. We're now gonna turn to the Q and A for the session. Just a quick reminder that anybody can ask questions either via email at investormegaport dot com or alternatively at using the q and a function in Zoom. And whilst perhaps OpenExchange line up some of the questions, I thought I might start with a relatively simple one that's coming via the q and a function. And the question is, why would a customer use SD WAN over MVE to connect branches versus just directly directly over the public Internet?
Maddie or John, is this something that, either of you can take?
I can take that. If you think about the regular Internet, the Internet is comprised of many, many networks connected together in an ad hoc fashion. Now if you think about what you get when you connect two branches together using different network providers in different geographies, that end to end experience is really determined by the quality of those connections between those Internet providers. What we've seen, I think there was a very good presentation at Cisco Live where Cisco used, their Thousand Sized Eyes product to look at the connectivity between two locations and the bandwidth that could be, utilized by a customer connecting those two locations. And what they discovered that when they go to the Megaport network, the connectivity was more consistent.
They got better throughput between those two locations and had a better, experience when it comes to a facet called jitter. It's a measure of network quality. Additionally, when you're moving large workloads, the inter the Internet, the the fragment of traffic that you're sending over that Internet connections is limited to 1,500 bytes. So when you're moving large amounts of data, that becomes a significant hurdle. On the Megaports network, you can go to larger maximum transmission units, the size of those packets.
So it gives you better end to end behavior, better end to end bandwidth. So just those are the major differences between what you get over the Internet and what you get over the Megaport backbone.
Thank you, John. Operator, do we have any questions in the in the waiting room?
Yes. We've got Tim Plum coming up right now. Hi,
guys. Can you hear me?
Yes.
Yep.
Hi. It's Tim Plumm here from UBS. Just a couple, if that's alright, from me. Thanks for walking through that presentation. Just focusing on that use case or the second use case with the Fortune 500 US company.
Can you give us a sense out of that $15,254, how much of that would Megaport get net of those IP transit costs? And and are there any other costs that we need to take into account when thinking about that customer?
Hi, Tim. It's Vinny here. Yes. So the IP no. There is no other cost.
The IP transit cost, which is in the schedule that you would have seen on the pricing that's included in the overall bundled price for the MB instance. The VXCs don't have any associated costs because that's already where they're already being consumed across our existing network. There is one other additional cost, which is it depends on where, as Rodney outlined, it depends on where the sales motion comes from. If obviously, if it's a direct sale, we have our own sales team and inherent commission costs associated with that. Whereas, if it goes through a third party, there's the an external commission, on that.
And that range that ranges, it it's a circa anywhere between 1520%, excluding the IP costs. And I I should also point I should also point out that there is a a special revenue share arrangement between ourselves and Cisco, due to the the extended, integration work that we're doing and being included into their, global, product list, which in in turn drives, huge volume for the business. So that's a that's a separate arrangement.
Got it. The second question's still around that second use case. Just in terms about just in terms of the deployment for that actual company, I mean, you showed us how easy it was to set it up on your platform. Can you walk us through the next stages that that company would have to undertake to actually transition their back end system or or or their business across onto it? Is that a project that would take a matter of weeks or months, or how how challenging is that from their side?
Matt, did you wanna take that one? I mean, I think you touched on it in terms of what the customer brings to the table. Ordinarily, Tim, the customer would already be, in this particular case, an SD WAN provider. They would have already had that, so it's a matter of them. It would have been a quicker process.
It was very quick for them to set this up. But maybe, Matt, you're closer to this this live customer if you wanted to talk that.
Oh, Vinny. I think it's similar to our existing products and, the customer journey. So in that use case, we've gone small. The customer, it it only has taken them a a matter of weeks to stand up. However, it will be a a long term migration.
So we we are expecting that customer to grow with us over the course of the next twelve to twenty four months as they move some of that legacy infrastructure. But as Vinny pointed out, they already have the SD WAN vendor already they were already using them. It was now just a case of establishing it on our network edge rather than to the cloud providers directly. So it it only takes a matter of weeks.
Got it. Thanks. So I'll jump back into the queue to ask the other questions.
Alright. We also have Paul Mason joining us now.
Hey, Paul.
Can you can you guys hear me?
Yeah. Paul can.
Yep. Okay. Great. So the first question I had was just if you could maybe go through the products defined both in terms of bandwidth and in terms of the number of virtual CPU resources that are allocated to it. Could you maybe give a bit of an explanation about why you need to increase the the number of CPUs attached as you scale up the the size of the bandwidth on the on the service and the and the number of endpoints that are talking to it?
Sure. Sure, Paul. Let me let me answer that. You have to remember that all of the majority of SD WAN traffic is over encrypted sessions. And, you know, with current modern technology, every encrypted session typically has a maximum bandwidth of about 1.5 gig.
So as you increase the number of branches, you act and the number of connections that you're making to that MBE, you have to think of that encryption overhead, and that's where the number of vCPUs come goes up to deal with that, decryption task. The decryption task is a pretty heavyweight activity on, modern modern CPUs.
Okay.
Great.
And just in terms of how the SD WAN Orchestrator interacts with with Megaport Virtual Edge, so the the use cases you guys have provided, I think, sort of basically imply that your your expectation is that the orchestrator will live on Megaport infrastructure whenever Megaport Virtual Edge is deployed side by side with an SD WAN vendor's solution. Are are you ever expecting that to not be the case and and and for the SD WAN vendor to sort of build next door instead of just pushing their software onto your infrastructure?
Let me let me answer that in two two two bits. The first one is that the SD WAN Orchestrator, the the the thing that manages all your SD WAN connections, that's typically a SaaS based solution by that SD WAN vendor. So in the case of Cisco, it's a technology called vManage, which they host. It allows you to manage not just, you know, Megaport deployed SD WAN edges, but everything you have on a branch or or data center footprint as well. So each one of those vendors has technology that they stand up on their own using, SaaS technology.
Does does that clarify your question?
Sort of. So in term in terms of how the virtual edge talks to that so that the orchestrator can sort of use Megaport's network, is is it is it going to be living in the same data center but in a separate rack, for instance, to Megaport's infrastructure, and then you're gonna cross connect into that? Or is it actually you know, is the better outcome for it to live on Megaport servers, you know, and and you provide the infrastructure of the service that's backing up the software as
a service? Does that does that make sense?
Yeah. So that typically, they're doing a SaaS deployment. That control function is typically located in, you know, a cloud provider somewhere or or in a in a data center that's controlled by that SD WAN vendor. They talk when they do the deep integration with us, that connection is over an API to our public API endpoints. So they talk directly to the APIs that we provide that allow them to control an MBE instance instance or or a a VXC on our network.
That's the way that Cisco has done the integration. So they talk from their SaaS enabled control function over our to our APIs to make and orchestrate those connections.
Okay. Great.
I suppose I suppose just, Paul, just one other thing to overlay that. Not all of the SD WAN providers are going to continue to build out infrastructure to support. That's they've they've got their central hubs, and this is where they're relying on partners like ourselves to actually extend that reach, and that goes back to what I was talking about the platform at the end of it. So, you know, there's a huge inherent value in the platform and the network that we've built and all the locations that we're in, and that's what's augmenting this heavy lift and allowing for greater customer reach both for the SD WAN provider and for ourselves.
Okay. And and last one for me for now, and I'll I'll jump back in the queue. But it's just on on Versa Networks, which is one of your more recently named partners here. My understanding of their business is that they historically have provided customers with their own sort of global map of points of presence and a a sort of global backbone of dedicated bandwidths that, in effect, had had tried to do what you you appear to be doing for these solutions themselves in in one holistic package, and now they've decided to partner with you. I don't know if you can share sort of anything about sort of why they have gone away from trying to do this themselves and instead partnering with with your network in order to provide that solution.
Matt, did you wanna take that one? I I don't think they're stopping from doing what they're existing doing. I think they're just using us to again, like I said, it's an extended reach to them.
Yeah. It certainly extend. You know, I think it's not only is it the 21 locations now where their customers connect to you know, we're seeing that demand from our existing customer base, which they see coming through it directly, but but also the cloud interconnect points and the reach of those cloud regions and the applications.
Okay. Thanks. I'll jump back in the queue.
Right. We have Bob Chen from JPMorgan joining us now.
Hey, guys. Thanks for taking my question. Just just thinking about the potential take up rate of MBE, what what's the best way to think about it? I mean, just given, you know, Megaport's core product did take a little bit of time to sort of get adoption or or to you needed to do a bit more education of the customer base. I mean, do do you think something similar will happen with MBE?
I think hi, Bob. I our assumption is, and we can only work off what partners are doing, as Rodney has outlined, you know, not just in the last quarterly update, but what we had in our go to market motion is is about extending our access to the partners and the resellers that actually currently resell SD WAN today. And by doing that, we we get we get a greater reach. It's also it's also solving a problem. As I said, like, the network as a service element of our platform is is lacking as we've talked about it.
I know we can get a bit technical in some ways, but at the end of the day, that's the part that's missing and that we're solving for. And and we believe that, you know, it this this will be faster than the existing business that we started out with rolling it out. These are technologies that's that is known and it's understood by enterprise customers. There is the overwhelming demand to connect the public cloud provider. And as John outlined, that's a difficult process today for both security latency, network performance, cloud application performance over longer distances.
And in the user cases, you can see how quickly that we were able to deal to with that for the customer. So we anticipate I don't know, I'm talking to Rodney. We already and this is just on our side of it, not with the reseller side. We already have a pretty strong pipeline building of customers and, like I said, proof of concepts that we're finishing out. And this user case that we talked about here was a proof of concept that we were talking about three or four weeks back, and it's now come to fruition.
And we have a couple of more of those that will be going live during June. But maybe, Rodney, if you wanted to touch on on that a little bit more.
Yeah. I would just say, you know, early indication as we talk to, the top partners from these vendors and to the leaders in of the SD WAN sales teams, there's a definite customer need. The value proposition is very clear, and the value that we provide, to customers, just extends the value that customers realize from the vendor's SD WAN solution. So, as Vinny said, you know, our pipeline is very strong, already and building, very rapidly. So, I believe that the the uptake on on this product and the knowledge, you know, of our product in the market is going to happen pretty quickly.
We're already seeing signs of that.
Alright. Great. Perfect. And, just bringing it back to, use case to, like, Tim earlier, in terms of, yeah, that 15,000 per month number, like, how would that compare to what that customer was previously spending on Megaport?
I can help answer that. So they're roughly, I think, spending from memory around just over 2,700 a month. So now they they they will be reaching about 15,000 a month. And so, of course, a lot of that has to do with the transit, but also the VXCs associated with that now too. So connecting those branch locations back to their private infrastructure that they've had with Oxford or the VXTs to to those cloud applications as well.
Alright. Perfect. And in terms of, you said target customer base, I mean, do do you do you expect a different sort of customer base to what you're currently targeting, or more of an expansion, or is there some, overlap there as well?
Well, keep in mind that today, we're selling very well across every industry. There there's not an industry that we're not touching today or have a logo in. So I think, as we look at those customers that meet the profile that have those branch locations like the, you know, use case use case example that that Matt pointed out, we're looking across our existing customer base and those that meet that profile. We have, a set of questions that we're approaching those customers with already proactively to identify, you know, the need and to, start the selling motion. And then from a, you know, Cisco, Fortinet, VMware perspective, the same thing.
Those customers that already have SD WAN solution are in the process of buying, have identified a need for our solution based on what has been outlined in this call, and we're approaching those customers as well. So there's, no shortage cross industry, be it retail, finance, manufacturing that have a lot of branch locations that have a need for this product.
Alright. Brilliant. Thanks, guys. You
bet.
Alright. We now have Matthew Dulgent from Morningstar joining us.
Hi. Can you hear me?
Yes. I see. Yep.
Thanks for taking the questions. I guess I'm looking at slide nine and thinking about those customers that already have been on an SD WAN solution. Is your solution geared mostly towards those that have already had it and it's actually better to go to Megaport also? Or are you targeting mostly towards those that are setting up setting up new SD WAN networks? I guess I'm just wondering what the value proposition is once you've already gotten that first step of complexity out of the way on a traditional SD WAN network.
And then my second question is actually just how you guys look at the future of SD WAN if we end up with a more distributed workforce with more work from home. Does that lower the need for it just because enterprises, despite how it might be better for the branch office, they have less need for it with with fewer workers maybe in the branch offices? Thanks.
Thanks, Matthew. Well, I'll touch on it first, and maybe, Rodney, you can add a bit more color. But look, it's both. Right? So we see this the reason we've seen most of these providers were collaborating with arrangements is that not everybody is is one using one of those vendors.
They they pick and choose the same as they pick and choose their cloud vendors. They are all they all see this as growth vector in their business, their these products. So it's it's a it I think there's a slide there we had. John had the slide. I think it was the slide yes, Slide 10, the one after that where it talks about the revenue growth over the next couple of years in this space.
So it's a growing market, and that's the first thing. So yes, we are seeing it come from existing customers. As Rodney said, we're looking profiling those customers that we have today. But more importantly, this is seen as a growth engine from the SD WAN providers. And so we're seen as an enabler or a fast tracker for customers to get network connectivity using their product to what the customers are looking for, which is to solve for predominantly to from branch to cloud.
And that's that's basically where we're sold. So actually both as a growth market. It's also worth targeting our our existing customers. And just to touch on the second part, we're not really seeing that. From what we're seeing in most businesses, it's, as I said, it's a growth pace that people are looking to use SD WAN to make other things easier for them, whether with existing legacy infrastructure or connectivity or for more diverse or more more edge connectivity.
Not not how we haven't really come across anything at this stage say that that, working from home and less branches and less offices is, is gonna have a diminishing impact. But maybe Rodney, ask him to let you take.
Yeah. I mean, one of the beautiful things about this product that every salesperson loves is the how easy it is to set up and and demo, and show the performance, advantages, very quickly. So for existing customers, that we're approaching, and Matt showed a few examples there. We're very you know, we can very quickly, prove by using the actually using the product that the performance is is better, and that, there's, you know, a lot of advantages in terms of not only connecting their branch locations, but connecting to the cloud, and avoiding, you know, some of the costs that they're paying in egress fees and and other things. So, it's it's, the value proposition is clear.
The ability to demo the product is very easy and quick. And, you know, it looks like the sales cycle, is going to be, you know, you know, fairly quick, know, in comparison to our ports right at right in the same lines, if not if not quicker than than selling our our port product.
So just as far as the network architecture goes, if you do have more employees working from home, do they still, do the the company still get the benefit of this SD WAN network? Or for employees working from home, are they kind of excluded from this?
Yeah. I I let me take that for a second. You have to remember what what are the applications that those employees are going to? These are all on private, on network applications. So like in in a health care setting, it might be, you know, cloud based radiography and imaging.
Or in a, entertainment environment, it could be manipulating assets in cloud that are are doing film production. I think we've done a a great video with, Framestore on how they use that. So all those applications are private applications that come over the private enterprise network. As employees move to a more work from home environment in those situations, they still need to get to those private applications. And, you know, they want to get them over a private link to cloud.
They don't wanna use the public access, especially when they have, applications that are very sensitive, you know, the the the core IP of companies. So we we yes. You know, working from home is going to change the enterprise network. SD WAN will help that in allowing, you know, workers to work anywhere, but still contain you know, they have a mechanism for connecting to that enterprise network that gives them private connectivity, to cloud. I I would say that eventually, you're gonna see some of the SD WAN vendors realizing that trend and be able to provide that SD WAN functionality to a home worker, not just a branch office.
You know? Granted, that will mean more connections to those hubs, and they might have to change their software architecture to facilitate that. But I you know, the work from home, yes, it's a it's a change in the way enterprise networks need to be built, but the access to those private applications still needs to go over, you know, dedicated private links that, SD WAN facilitates.
That's very helpful. Thank you.
You're welcome.
We now have Nick Harris from Morgan joining us.
Nick Harris here from Morgan's. Can you hear me?
Yes. Hi. Good morning, Nick.
Wonderful. Hey, Vinny. Thanks very much for this. Just a couple of questions from me. Just on the, MBE sales model within Megaport, are you, retraining your existing salespeople to sell MBE, or are you adding new salespeople who will specifically focus on this?
We're training our existing salespeople, and we are adding primarily solution architects that can support, not only our sales team, but also the partner sales teams to identify and progress opportunities. So, some of both, we're hiring and we're, you know, training our existing team as well.
Thanks very much, Rodney. Just also interested, I guess, from the perspective of your big providers like Cisco, where do you think SD WAN sits in terms of their sales priorities? Obviously, they're very big base. They got a lot of things going on. Is it something there you think they'll actively push, or is it more customer demand that's driving as in pull rather than push?
Well, I I'll have I I can have Maddie, chime in on this one as as well. But the feedback we're getting from, the sales team is that this is, one of their fastest growing areas of their business is SD WAN. So they're getting, you know, not only pull from the market, but also, you know, push from from their partners, as well. But, the feedback we're getting from the partners and the direct sales team is that, you know, there's focus here, there's demand, and it's one of the fastest growing areas in their portfolio. I'll let Matt chime in as well.
Yeah. Thanks, Rodney. I I they haven't been given sort of a specific number from Cisco. However, we're certainly working with them. You know, just to recap on what we presented earlier, once we're on the global price list, their sales team are incentivized to sell this.
Also, their partners are incentivized to sell this through the Cisco rebate system, through their special incentives. But, also, you know, they're they're certainly seeing the demand coming through, particularly when they're rolling out new router infrastructure. So the c eight k v, it's sort of established, like, as a a bundled sort of package. So when they when a when a customer goes and and purchases at c eight k v, they're going to get access to to Megaport services as well. And that and that's how they're sort of driving those sales because they want them to to buy it through Cisco direct rather than going going and buying this through some of the other partners that they've they've got this infrastructure hosted on.
That's great. Suppose the other thing just one other thing to add to that, Nick, as well. I mean, and this is sort of public knowledge. I mean, Cisco being a public company, they are, very much focused on trying to drive monthly recurring revenue streams as opposed to, you know, some of their traditional business, which is just selling hardware. So, again, this is value added services is seen as a high growth area within within Cisco.
Great. Thanks, guys. I might just sneak into ones which are hopefully be quicker as well. Just just to clarify, does Megaport pay commission on the Megaport virtual edge plus the VXCs, or is it just the virtual edge? And then the second question was just cybersecurity.
Obviously, when you've got a branch out in the wilderness, you've got to protect some of that. Do you guys provide any of that, or how does that work? Just the cybersecurity side attached to the MBE.
I'll answer
the first part. Maybe John will take the second. Yeah. We'd commissions are usually on a bundled price, which is the way we've structured it, excluding the IP transit. That's that's a typical format globally.
So and and it doesn't differ from the way we do things today with the remaining or the existing products. On the cybersecurity piece, John, did you wanna take that one?
Sure. I mean, we don't do anything specific to the branch. What we do what SD WAN does allow you to do is take those sensitive workloads and put them over an encrypted pipe to the Megaport virtual edge. The other part of most of the SD WAN vendors' solutions are they do offer a full suite of security functions on that, instance that they're running on the virtual edge, whether it be firewall, deep packet inspection, application inspection, things like that are all offered on those platforms. And and customers may take advantage of those security functions to protect the applications that they they may be running in data center or cloud.
Thanks, John. So it's more like it's Yeah. Wrapped into the bundle rather than they get a VXC to a security solution?
Yeah. Correct. But, again, it's it's another one of those areas that we would see similar to SD WAN as a suite of security products like that with other partners that we would we'd have hosting as well. So customer, if they just want those services, they could get them directly to. So that's something we've talked about is the involvement SD WAN as the first set of providers that we're using on MVE, and we talked about other things like IoT, five g, security, etcetera, as other different buckets of areas where we can we can host on MVE.
But, yes, right now, if, most customers, if they're using an SD WAN provider, they can actually choose those services via the application or the managed service.
Excellent. That's it for me. Thanks again.
Thanks, Nick. We now have Wei Sim joining us.
Hi, guys. Can you hear me?
How are you? How are you?
Okay. Great. So just three quick questions. First one is just in regards to our partnerships with Do we have any type of, you know, performance bonuses related to that if they sell a Brazilian amount of of our product and at what levels would that be set if we do?
You mean with their Salesforce or ours or in general, total sales?
Their Salesforce, if they were to, you know, sell beyond a certain level of. Okay. No.
No. There's no. There's not. We've agreed we've we've agreed revenue share with our Cisco partners, and that's set in motion. We review it periodically, like, either twelve or eighteen months period.
It's It's set in a way at the moment to incentivize large volume uptake, which is what we both want. So that's what we've set it that way. And obviously, we're gonna continue to support it through marketing initiatives and and as well. So that that's the whole purpose of that. But other than that, no.
Everything else is we're that's mainly the rest of the reason is to sell with our partners. So they have resellers, etcetera, but for system integrators out there that that actually actively sell those SD WAN products, and they're the ones that we're working closely with, not just to sell SD WAN products, to sell our existing products as well, like ports and VXCs.
The second question is when our direct sales, do they also have a function to cross sell Cisco for the VMware's products? And if so, we kind of get commission from them if we do that?
No. We're not it's no. So first of all, we're we're only selling we're allowing the customer to choose which SD WAN provider they want to use and obviously have to have a a relationship with the s d one provider to obtain either CP or the license that that they need to use the service. We are not actively engaged in selling that. That's that's, we're, you know, that we're going you're going into an area that's not something that we're we're core at.
It's the same thing if I bring back here an example. You know, we early days when we started out, we brought on all the cloud providers onto and fully integrated with them, then we built out the global connectivity with all the cloud providers. And the same thing we're going to do with the SD WAN providers, and we'll do that with other providers as we bring them on to MBE. Their their competency is selling their product. We're just facilitating the connectivity to the enterprise customer.
Okay. Understood. The last question that I've got is just on our slide 14 of the presentation. We talked about the 21 locations that we have right now. How do we see that number expanding over the next few years?
Do you have any guidance for that? And what is the cost of expanding our footprint
for each location?
Matt, did you wanna talk about phase two and phase three in terms of locations?
We can't really talk we can't really confirm phase two and three. It's still in, I guess, discovery phase.
We're just giving a rough idea of numbers, I think, not locations. So
Yeah. I think it's like Yeah. I can't I can't confirm that.
Yeah. I think it's additional 20 that we have in for the budget for this next year, so that's a different 20 cities. And in terms of the cost of what that is, it's typically hardware. So we're already in that location physically with our our existing equipment. So we deploy we deploy this compute at each one of those new cities or new sites that we deploy into, that's mainly hardware costs.
So depending on how much we have to deploy, it's fully loaded. It's around $35,000 per location.
All right. We now have Suraj Ahmed from Citi joining us.
Okay. Hello? Can you hear me now? Yes?
Yes. Hi. How are you?
Yeah. Sounds good. Thanks. Just just just looking at it. I you're the target customer.
I mean, we
spoke with the partners, but from your 2,100 customers that you have today, have you just tried to map out how many would be addressable from this new solution?
I don't have the exact number, offhand.
Is it, like,
10 is it 10%, 20%? You know, just trying to understand that.
I would say it's, at least 25% have, you know, meet the meet the profile, but it's hard to give an exact number. Plus, it's early days. We're still, you know, looking at our customer base and approaching, you know, customers that, you know, the product's only been, you know, GA about fifty days. So we're still, you know, asking the customer questions about their architecture and their the number of branch locations and such they have to identify, potential customers, which we're still, you know, proceeding with. But, there there's a good amount of our customers across industry that meet the profile.
Got it. Thanks. And, Rodney, just thinking about the target customer to the partners, when given the incentive is when should we be thinking the new to SD WAN customer would be the typical customer now because, you know, the partners would be selling SD WAN and then this sell on MBE? Is that the way we should be thinking about it? It's really future growth future SD WAN growth that you can tap into mainly?
I I think it's both. You know, I think there's there are existing SD WAN customers that that, you know, need this solution. I I wouldn't say it's just new. I think the selling motion is more, smooth and natural for for new customers to, you know, include Megaport, you know, as part of the total solution. But going back to existing customers, and giving them, the advantages and value we can provide, is good for existing customers as well.
So I I wouldn't say that, just new SD WAN customers are the ideal target. I I I believe it's both.
For the existing ones, you'll have to use your sales team the inside sales team. Is that the way to think about it? Because the incentive of
the partner is the future. Okay. Okay.
Yeah. No. No. We'll use, you know, the the partners, of the SD WAN providers and also the the direct sales teams of those providers. Keep in mind, you know, we retire quota because we are on their price list, and everyone in sales wants to retire quota and and reach their targets.
Same with taking advantage of the partner, you know, their channel program advantages and benefits by by selling more because we're on the price list. They can take you know, use sell our product to take advantage of those benefits. So going back to existing customers and selling, it is, you know, a path of low hanging fruit. It's always easier to sell to an existing customer than to approach and try to sell to a new customer. So I think there's going to be both, and that's certainly what we're targeting in our go to market and our selling motion is to target both existing customers that Cisco, VMware, Fortinet can easily help us to approach as well as their partners and, include Megaport as part of their new solution sales as well.
Got it. That's a good point regarding the quotas. Just last question for me. I mean, we are talking on SD WAN today, but you you were hinting at future functions at near also on MBE. Can you just touch on, you know, how we should think about that and, you know, just just give us a flavor of what the future stuff could be?
Maybe, John, you can take that.
Say that again?
You started with an analogy of with MBE and SD WAN, future functionality on top of MBE.
Wow. That that's a that's a really good question. I you know, part of it is a lead from the SD WAN vendors on where they're headed. You know, they've they've it's a fairly mature product, so you don't see any dramatic changes in functionality in functional space. I think with some of the integrations that we're doing where we can integrate further with the SD WAN partner, most likely, it's better visibility into our network assets and ability to, select paths deep within our network for, you know, optimal latency or experience.
But I I don't think that's anytime soon. This is a a much longer term approach.
But I think so as you're talking about what I mentioned earlier on about five o g, five g IoT Yeah.
Five five g IoT.
Yeah. Yeah. Okay. Yeah.
Yeah. Not not necessarily SD WAN yet. Yeah. Look. We do have we do have some conversations heading on, but they're in early early stages with certain partners about that capability.
So, I mean, bear in mind, we've just launched MBE. We're really in the middle or the throes of of lining up a couple of partners like we've just outlined today and getting this up and running. So I think that's going to be our focus for the next certainly for the next the rest of this calendar year, and and we'll continue to be as part of business as usual from that point on. But the future development in terms of areas that will that will sit across MBE, We have we have a few in each one of those areas that are in their infancy, so it's it's probably going to be post '20 2021 before we start talking about something with that.
Got it. Thanks. That's helpful.
Alright. We now have Paul Mason joining us again.
Hi. Can you guys hear me again?
Yep. Paul.
Oh, great. Okay. Just a couple more from me. So just in in terms of redundancy, just in in the two use cases you provided, in both examples, the customer only purchases one MBE per city, and then they're purchasing sort of two cross connects, which I think is for redundancy. But can you maybe give a bit more sort of background to why they first of all, why they have two per cross connect per MBE and then also why they only have one MBE?
Because I I think historically, you talked about a lot of customers say with ports, they'll buy a second port for redundancy and and sort of why why that might not be the case for an MBE?
Let me answer that. First of all, the the two VXCs that they're purchasing, the reason they're buying those is to match to the SLA guarantees that cloud providers are are offering by requiring those two connections to offer those SLAs. I think we you know, most customers are probably going to purchase either an MBE instance in one metro and another one in another metro to have that redundancy that we've talked about, or they'll do two in one metro. And it sort of depends on how they're, building their network fabric and what the latency characteristics of that network fabric are going to be. So with applications that are tolerant to a little bit more latency, they might do one in one city and one in another.
But for applications that are not tolerant to that, they'll probably do two in one metro. The other bit that we've done from a redundancy standpoint is, you know, we we talked about DDoS, for instance, as a functionality. The other function is that we, you know, are selecting routes from multiple, transit providers in those metros so that we have transit provider redundancy in those metros. We're deploying two MBE instances in every metro so a customer can select, redundant MBE instances in those metros. So, you know, if you think about it, Megaport has always strived to offer an enterprise everything they need to build a bulletproof network, and we're doing that additionally with MBE.
Okay. Great.
The other thing, Paul, is that that user case is the smallest instance that you can come up with, right, combination or configuration in terms of customer in one metro in this illustration connecting seven branches, connecting to one MB, you need two VXCs because of the SLA for the cloud provider for redundancy, and that's the smallest. If you if a customer wants, like, what we saw in the larger case and you've got multiple cities, the connectivity is there. If you want to go branch to branch from, say, somewhere in Sydney connecting to Melbourne, you would have two MBEs, and you'll have, you know, two you know, obviously, customer will have two instances of of their SD WAN on either end connecting to the data centers in each location. So it depends on the application, you may not need and and, obviously, the number of EXCs you need is obviously created, as you saw on the large example, to a a bigger footprint and more locations.
Okay. Great. And just maybe an extension of this question then. In terms of the latency to the edge, you guys gave some stats about the improvement that, so to speak, Fortune 500 customers experienced. Like, in terms of sort of globally rolling this out, like, are thinking about this in terms of, like, their maximum path to the edge of, like, twenty milliseconds, or is is there a stat like that that from a competitive or customer experience perspective, you need to sort of build build out
towards, you know
sorry. Go on.
Yeah. I would say it's, you know, the the we always think about application latency. That's from where the consumer is using the application to wherever it's hosted, and you want the most direct path. So what we're trying to do is make sure that we're in that latency path regardless of what cloud region you're using. So it's it's it's a complicated formula that has to do how quickly can you get to a Megaport virtual edge.
But then, again again, you know, what is the latency path to that cloud based application? So, you know, part of our design consideration has always been put MBEs in locations that will help a customer minimize, that latency path to their application. You know, could I say it's ten milliseconds maximum latency? Yeah. But that that that would not be that would be nice, but it's not prescriptive.
You know, it depends on the geography. It depends where the cloud region is and where they're on, you know, where they wanna meet us.
Okay.
Yeah. So so say, like, on East Coast US, where you've got New York, Boston, Washington, in relatively close proximity, there could be logic to deploying in all three cities instead of just saying, like, in in in New York in the in the central part of that sort of chain of population, for example? Or
Yeah. So what we've done there, if you look at the we've tried to deploy close to the cloud region. So you know, as well as make sure that we cover enough parts of the the Eastern East Coast Of The United States. So, you know, New York, Atlanta, Ashburn, which is in in the Washington DC area, as well as up in Toronto in the Canada. So trying to get all that traffic onto our network and then to the cloud regions regardless of where they're at.
So in in The US, you you see a fairly, you know, we're fairly covering the whole, country. But even in Australia, you know, we're deployed in both Perth and Sydney because we realize that you don't want to if you're running a workload in Sydney, you wanna get over a quality network to get to it even if you're in Perth.
Yep. Okay. And just the the last one for me is more about sort of first mover advantage because I I think, like, with Megaport historically and the and the data center partnerships that you guys have struck, you know, the the nature of them has sort of informed that, know, somebody else couldn't come in side by side, like, say, you know, with what you guys have done with Digital Realty or or or
You know, there there was sort
of an opportunity for one. With with virtual edge, I mean, how do you guys think about first mover advantage, you know, in in, say, like, Cisco being managed console? I know I I believe there's sort of probably room for another vendor to appear side by side, but but probably not that many. Yeah. Could you could you sort of frame up sort of how how you think about that?
Yeah. Well, I think and just answer the Cisco piece. I mean, I think, you know, I I we were asked this question before where we want to be, you know, exclusive, and the answer to that was no. And and it's the same on Cisco's side because they're obviously looking to use as many partners. That's the way they set themselves up.
They leverage partners whether anything for to give them reach on sales growth. And we're the same. So we didn't we want we saw that. And if you look at that chart on the on the that John presented on the market where we talked about the the quadrant. I mean, you know, the VMware, Cisco, Fortinet, and Versa account for 48%.
Those four loan come for 48% of the market rate. So, you know, we didn't wanna be kinda limiting ourselves to one area or one sliver of that quadrant. So, you know, the whole idea is to to get that reach. And and so, yes, MBE is the first mover. We're the first ones to do this.
The full integration with Cisco is the first of its kind. You know, both both of us have recognized that in what we're doing there. It takes a lot of work to do it. We've been at that, god, more than eighteen months, maybe two years since inception when we first thought about doing that. So it's not something easy to do and replicate.
It takes time, which is why, you know, we've we've come out with this, and we want to make sure that we make make the most amount of noise about it. And, again, what we're trying to do here as well is leverage the platform. Right? So like I said before, we've done the physical network. We have all the data centers connected.
Now what we're doing is we're layering products over all of this, and this is just one. And now it's opening up a door for us to bring more providers onto the network so customers have more choices about driving customers towards the Megaport platform so they can either connect in a data center to cloud or from a branch into our network or just use it as network as a service. And as we continue to layer over more products and we grow our existing global network with either new markets or new countries, it just continues to self perpetuate. And that's that's the way we see it. And and there isn't anything like that today.
And to build that again, like I said, it's still going to take time and a lot of money and a lot of effort. So what we're trying to do is go further and further deeper and getting closer to where the customer or the enterprise is using most of the providers and doing the API integrations with those to bring all of that and to make that easy consumption or easy way of consuming provisioning services. And that's the mantra, that's how we're how we look at it. And and there there isn't anything like that today that's out there.
Okay. Great. Thank you.
Operator, I might ask. We've had a bunch of questions come in via e mail and via the chat channel. I might just ask a few financial ones that Sean might go through. The first one relates to OpEx and what will happen to OpEx with the particularly in FY 'twenty two with the addition of SD WAN resourcing? The second one, it's the follow on to that is, does that impact Megaport's ability to achieve EBITDA breakeven on a run rate basis by the end of FY 'twenty one?
And the third one is what's the cost to expand to additional MV locations beyond the 'twenty one that have been nominated?
Okay.
Well, just taking the OpEx question first. SD WAN itself doesn't necessarily add that much OpEx, and and we are going through a a a scale up of our indirect sales channel, and the additional head that we'll bring on to support SD WAN will be will be part of that. So in itself, it's it's not significant or not material step change in terms of our our head count in and of itself for SD WAN. As part of that, we will be supporting this additional indirect sales build And as the border returns to normal, we'll hopefully start attending events and start traveling a little bit as well.
So that adds a little bit more of of leverage in our journey to EBITDA breakeven. We're still on target to do by the end of this year as most of that additional spend will will be ramped up through h one of next year. So we might not be out
a little bit of
a cost, but our operating leverage is so that, you know, even if we do take a a backward step for a month or two into into FY '22, we'll we'll be straight back, getting towards EBITDA breakeven and and EBITDA positivity throughout the next financial year. In terms of how how much it would cost to expand these NV locations, Finney mentioned it earlier. This is just an a CapEx cost for us. We are already in the locations. We already have the space.
We already have the power and the connectivity. So it's just CapEx for the computer we'll be adding in occasions and the the $30.30 grand, it go it's it's just a one off cost. We're not adding any more cogs necessarily for for this expansion for phase two and phase three.
Alright. We now have Tim Plum joining us.
Hi, Tim.
Hi. Sorry, guys. Can you hear me? Yep. Okay.
Sorry. Just two follow-up questions for me if possible, please. Just going back to that second use case that you gave. So $15,245 cost under the new structure. Can you give us a sense how much it would cost to set up a structure or the operating cost to set up a structure under the old traditional SD method?
That that's a that's a complex question. It it it would have to go not only regional issues, but also network design. But to give you a sense of some of the costs that would you'd have to incur depending on where your workload is. In a data center context, if you want to set up SD WAN, you'd have to purchase the equipment and the transit connections and assuming that you have Rackspace in that that data center footprint. On the cloud, it's very similar.
You have to purchase the virtual instance, the software license that you're running in cloud, and then, rather than transit connectivity, you'd have to, pay for the, egress costs of data on that public cloud endpoint. You know, our ROIs on all those situations put Megaport at a, cost advantage to most enterprises that are building that. Now if you were to look a little bit more traditionally, even before SD WAN and going to MPLS, that is a substantially more costly solution than anything that we've described to date. I think the best analog is both the data center footprint as well as the cloud footprint. And in our our analysis, both are more costly than the Megaport solution.
Got it. And just the second question. Vinny, slightly off topic, but just in terms of ports added, you previously mentioned that momentum was accelerating into the fourth quarter and that you guys had a number of new initiatives that could potentially further drive ports added. We're kind of two thirds of the way through the quarter. Are there any comments that you can make about some of those new initiatives or or how those ports added are tracking?
I thought I could get you this call without someone asking me that. It's going well. That's what I would say. We're we're happy with progress. Obviously, we're now into the last month of the quarter, but we're doing lot better this quarter.
So, yeah, we're we're happy. I'm I'm keen to get Rodney off this call because he can't get him back selling. But no. You know, we're we're happy with what we've said before and where we're at, and we still have a very strong pipeline. We'll continue to add to that pipeline as well as convert it.
So, yeah, we're we're happy with we're confident what we're for outcomes that we're driving for this quarter.
Great. Thanks, guys.
Okay. I think we'll then we're now coming up on an hour and forty minutes. Steve, is there anything else? Or are we moderate?
One question, Vinny, I do think is perhaps worth just touching on, and it relates to the share of revenue and the margins that we're anticipating in each of those. Sean, this is perhaps one for you using a real life example. This just relates to perhaps we start on use case number one, which is relatively simple, clarifying the RP transit and then the types of margins depending on where it comes through, gross margin and EBITDA margin.
Yeah. It it all it all depends really very much. If if we took a very small MBE instance, say let me go back to the use case one where we have a small NDE of 1,550, of which 550 is transit. We're gonna have two VXCs at $200. The the gross revenue, if that were to be the case, would be $1,950.
And if that was going through kind of a direct sale, the only cost of sales we would have would be kind of the IT transit that we would have to do. So, yeah, our our our gross margin then is obviously $1,400 of the $19.50. If it goes through kind of the partner resell model we talked about, we would have to we would have to give off somewhere between 1520% as using the standard kind of percentages that we get off. But that would be all the VXE costs, the the MVE costs only. So the the IP transit would be a cost, and we would we we would be given away about about $280 of of the the kind of 1,400 extra margin, that would give us a margin of about 1,120.
It's about 57%. In in terms where we go through a revenue share model, which is kind of a low touch model for us, where much of the sales function is is done through something like the Cisco platform, Cisco sales function, we would be sharing our our revenue and typically $50.50 after after the reseller cost as well. But, again, like we said, none of the revenue share or the the discount is is given on IP transit, which is just a straight pass through. So it would be the cost to us would be would be 550 for the IP transit, the same 280 to the reseller for which going through a reseller, and then we would have a revenue share of half of the remaining $11.20. So it could be $5.60.
So and whether the the the presentation on our accounts will be very much depends on on the commercial model, but, you know, if we were to to show in a gross gross presentation, we would be showing a gross margin of of $5.60, where if it was going through kind of the the revenue share model with our partner reseller and with IP transit.
Okay. We may draw today's presentation to a close. Thank you very much for attending our investor briefing on MBE. Today, we've run through an overview of both MBE and SD WAN, some of the MBE pricing and use cases, and then we've seen a demo from from James. From the q and a, there's obviously strong interest in MBE and what it means for Megaport going forward.
I don't think we've answered every question today, so please reach out if you have anything further. For those that have missed today's webinar, it will be made available on our website. And we've included on Page 24 of the presentation a bunch of reference materials that might help you get up to speed. In addition, we intend to disclose on a quarterly basis the MVE metrics as we're selling MVEs into customers, something similar to what we disclose on MCRs. If you have any more questions, please reach out at investormegaport dot com.
And just a quick reminder that our Q4 global update in Appendix 4C will be due out on Thursday, July 22. Thanks again for attending today, everybody.
Thank you.