Well, as mentioned, on-ramp for Multicloud, this is an evolution of our IaaS
offering.
So first and foremost, what is infrastructure as a service?
Well, in the last video, we mentioned that I had the on-prem option, and I also
have
the software as a service option, but if this is a spectrum, then right in the
middle is
the concept of infrastructure as a service.
infrastructure as a service is when I still deploy my own virtual machines,
because over
here on-prem, I'm going to deploy my virtual machines to deploy software on top
of hardware,
like my servers and my storage.
And we said, you know, that's complex to have to manage it.
It's expensive to purchase it, especially capital expenditure purchases.
I don't like those.
I would like to just run in the cloud, except what if we don't love the idea of
software
as a service for one reason or another?
Maybe it's compliance or security, or maybe just the cost.
Well, there is a middle ground, which is deploying our virtual machines into
somebody else's
hardware space, meaning that there's servers and storage up here in our IaaS
cloud, but
I'm going to log in and configure my own virtual machines and install the
software directly
to my virtual machines that just happen to be running in somebody else's data
center
somewhere.
There's plenty of vendors.
Microsoft Azure, as well as the Google Cloud Platform or GCP.
These are the three providers that Cisco supports.
Meanwhile, there's dozens and even hundreds of these cloud providers that allow
organizations
to log in and spin up their own virtual machines without having to manage their
own infrastructure
underneath it.
So this is what on-ramp for multi-cloud is all about.
And again, it started as on-ramp for IaaS and it has now become multi-cloud
because Cisco
recognizes that we live in a multi-cloud world.
I probably don't just have an AWS account anymore.
I probably also have an Azure account.
I might also have a Google account that I'm running virtual machines in any one
of these.
There's a lot of differences between the different cloud providers and we might
find that we
actually want to run all three of them and a lot of organizations do.
And so Cisco said, okay, instead of supporting a single IaaS cloud, we're going
to support
the multi-cloud world and we're going to evolve our product accordingly.
So we'll find out there are three primary use cases for on-ramp for multi-cloud
.
We have the concept of site to cloud, meaning that an edge is going to connect
to a virtual
edge.
So here I have a physical edge device in the real world.
It's connecting into my SD-WAN environment, which means that I've got all kinds
of IP
sec tunnels formed up here.
In fact, let's just draw this as having a different circuit here.
So let's just draw one circuit, circuit A. I know I've got another physical
edge up here
and I form my IP sec tunnel like this.
However, now what the on-ramp, well, just generally speaking, what the SD-WAN
solution
provides me is the ability to look at my cloud infrastructure and deploy a
virtual edge.
We could deploy that 8000V, for example, as a virtual device and now I can
connect it
in, usually if this is an internet connection, I can make sure that this has an
internet
connection and therefore we can actually form our full mesh of IP sec tunnels.
This is pretty cool, especially when we look at the fact that behind this
virtual edge
is going to be a bunch of networking that happens to be cloud networking and
different
cloud providers have different versions of cloud networking and this is where
my virtual
machines live.
So I've got a bunch of different virtual machines living off of this network
that is
now attached to the rest of my corporate environment thanks to this virtual
edge that is also
a virtual machine that was installed into the cloud space.
This is very cool.
And what we see is that the architecture looks the exact same even though part
of it
down here is completely virtual.
This is the world we live in now doesn't matter whether it's physical or
virtual.
It doesn't matter from a architecture perspective.
It's all going to look and act the exact same.
So the site to cloud concept is the first use case.
I'm going to allow my users who live out connected to both of these physical
edges here.
And now they need to connect to the virtual machines here that's running the
software
that I have installed out here.
Well now I can do so very simply thanks to my SD-WAN environment.
And that makes it so that connecting out to the cloud space is much simpler
than it used
to be where I'd have to build VPNs and maybe again from a traditional WAN
perspective introduce
a lot of complexity in order to properly manage that.
Well next we have another use case which is a little interesting.
Oh and it is worth mentioning that cloud for IaaS that's exactly what this
product was.
But now we're evolving this and showing that there are other use cases
including this rather
curious one which is site to site.
Think about what we just talked about in the last video.
If I have a super highway of high density, high networking capability then I
might be
able to get from one site to another site not directly but actually through a
different
network that's a little bit out of the way that is much faster.
Well what if this network is a cloud service provider.
That's exactly what we're talking about here.
Now the architecture looks like this.
I've got my users behind a physical edge and I'm trying to get over here to
another physical
edge where there's other users and other networks etc etc.
So what I normally would do is I'd make sure they're both connected into a
circuit.
Let's say this is just the internet and now they can form an IPsec tunnel right
?
Yeah absolutely this is the SD WAN architecture.
But what if this is this direct path and there would be a better potential path
if we can
leverage some high throughput?
Well again what if we did leverage a cloud service provider like AWS or Azure
or Google
and we leverage these virtual edges in order to make it so I can use their
global networks.
What do I mean by this?
What I mean is let's say this is in one region.
Let's say this is in Europe and this over here is in another region.
Let's say it's in the US.
And now let's say I connect into my cloud service provider using these virtual
edges.
And the cloud service provider doesn't matter which one I choose likely has
infrastructure
in all of the different major regions in the world.
Certainly the three that Cisco chose to integrate with have that capability.
And so now what we have is we have an architecture that allows me to form
connections across
very very I'll just keep drawing this line making it thicker.
Very high level network or high quality networking.
Again, we're assuming and it's a safe assumption that this cloud service
provider has very
strong networking capabilities among a bunch of different regions.
Now we're going to redirect ourselves a little bit to take advantage of that.
So now we can deploy this multi tier architecture.
Remember what we talked about also previously.
We have the multi region fabric.
And so now we've got this concept as well where I can build an IP sec tunnel
this way
and this way and this way.
And in the end, this is much faster potentially than just going through the
internet.
This has a fancy phrase that will explore more in the next video which is known
as middle
mile optimization kind of a cool phrase.
We talk about first mile.
We're talking about the initial connectivity.
We're talking about the last mile.
We're talking about what it takes to get to the actual destination.
But the middle mile is something we don't talk about a whole lot.
In this case, it's right in here.
We're saying that I could just use the internet to get out there to the other
side and build
my IP sec tunnel directly or I could optimize that middle mile and make sure
that I'm taking
the highway that is much, much faster than the bandwidth highway.
So again, we just got you out right here.
But the idea is I'm leveraging the cloud service provider simply to connect one
of my sites
to another one of my sites.
All right, so those are the first two use cases.
Now let's explore the third one, which is cloud to cloud.
So this answers a little bit of a problem that we might have if we do embrace a
multi-cloud
world.
The multi-cloud concept is that I have multiple different cloud spaces and
specifically multiple
vendors.
Now cloud vendors don't always like to get along very well.
They're not necessarily going to have all of the hooks, the native hooks to
make sure
that we can communicate from one cloud to the next.
So let's say that we have cloud service provider A here and I've got a bunch of
infrastructure
in here, a bunch of virtual machines, and then I have cloud provider B over
here with
a bunch of virtual machines as well.
How do I get these virtual machines to communicate with one another?
Well, this has always been very tricky and there are certainly ways to make it
happen
outside of SD-WAN.
But SD-WAN gives us an option.
I can deploy a virtual edge into each one of these spaces and then I can make
my IP
sec tunnels between them such that now we can communicate from one side to the
other.
So these are our three primary use cases, site to cloud, site to site and cloud
cloud.
And like we said, I'll wrote it over here, but we support AWS, Azure and Google
at the
time of this video.
However, even at the time of this video, Oracle Cloud, Cisco has said they're
going to
support by the time you're watching this, which is the speed at which things
move, chances
are Oracle may well already be supported at this point.
So when you're making your decisions, especially as it relates back to your own
corporations,
cloud environment, check in with Cisco and find out which cloud providers are
supported.
It might not just be these four.
Cisco might actually support more by the time you're watching it.
So now that we understand the general architecture, we do need to understand
how exactly we perform
edge deployment.
And when we're talking about edge deployment, we're really saying the virtual
edge deployment.
So there are different ways to deploy our virtual edges into the cloud space.
And we see in all of these solutions that these virtual edges are very
important to us.
So how exactly do you go about doing it?
Well, the first thing to recognize is that when we create a cloud space, we
usually have
some kind of network container.
For example, Amazon or AWS uses the VPCs and Azure uses the VNets.
The same concept, just a different phrase and a different terminology depending
on which
vendor you happen to be using.
And so the first option that we have is not going to scale very well, but it's
effective
for small environments.
I can deploy a virtual edge into each VPC and VNet.
And so as I expand to multiple VPCs or VNet or anything else, including Google
and Oracle,
I continue to deploy a virtual edge into each space.
Yeah, this is fine.
If we only have maybe a handful, maybe two or three at the most, if we have a
small environment,
we only have one network, then yeah, absolutely, that's fine.
It doesn't mean we can't use this solution, just be aware that if we have a
very large
cloud infrastructure, then this isn't probably going to scale very well.
So usually what we see is something along these lines, where instead these
cloud providers
allow us to have a cloud gateway service, typically relying on BGP, and they
are going
to handle the networking among all of these different virtual networks that we
're spinning
up.
Okay, so that's great.
And I know I don't want to deploy a virtual edge into each one of these.
So what do we do instead?
Well, we're going to deploy these.
It seems I can draw it.
There we go.
We're going to deploy our virtual edges into a dedicated space.
And this dedicated transit network that it eventually becomes is going to
interact with
the cloud gateways.
So we're going to be able to advertise our networks back and forth, usually via
BGP
once again.
So now, whereas before my edges out here, I suppose, so my physical edges had
to do
an IPsec tunnel into every single one of these networks.
So now if I have an edge, I can simply form IPsec tunnels into the virtual
edges here
at the, well, at the edge of my cloud deployment.
And that doesn't matter how many of these virtual network spaces that I have,
it's all
going to, it's all going to scale very nicely.
Now there is a third option.
And this third option is probably the most ideal, but it's also going to rely
on native
cloud integrations.
So this third option is actually going to be the one that doesn't involve
virtual edges.
What on earth are we talking about here?
Well, what we can do is we can actually leverage these cloud gateways here.
And so we can bring in our edge devices and connect IPsec tunnels in natively,
again, as
this third option.
Like I said, this does require some sophistication and configuration, but at
this point, we wouldn't
even need the transit network because we connect directly in with those cloud
gateways.
But again, that is something that we'd have to explore and make sure that it
fully is
supported by our environment and by our cloud vendor.
Now one of the most beautiful parts about this entire conversation is that this
might
still seem very complicated, especially if we don't have a lot of cloud
networking experience.
But remember, this is an SDN type of product.
And we have an SDN controller known as the SDWAN manager.
Manager allows for me to automate all of this.
And this is a beautiful thing.
I can simply log into my SDWAN manager.
I provide my cloud credentials.
I select whichever topology type I want, especially highlighting the virtual
networks
I want to connect to.
And it automatically spins up my virtual edges by leveraging the cloud APIs to
build out
whatever virtual network that I'm trying to build out.
So to be very, very clear, the virtual edges are automatically fired up.
This is beautiful.
I as the network engineer don't even have to go out and create the virtual
edges.
They will simply be spun up and brought into the environment as part of the SDN
aspect
of my SDWAN solution.
So primary takeaways from this conversation, understanding the three use cases
for my multi-cloud
environment, understanding the primary architectures that we can use to deploy
our virtual edges
into the cloud space, especially number one and two, because we need to
understand that
there's a difference in scaling with how we end up building this out.
But certainly understanding that we have that third option available as well.
And lastly, that all of this does get automated through the manager interface,
which just
brings the whole thing together in a very simple way for me as the manager of
the network.