Whenever we're talking about one of Cisco's on-ramp services, the idea here is
that we're
challenging the belief that the shortest distance between two points is a
straight line.
For example, if I was trying to drive to the grocery store from my house, and
let's say
that I've just happened to have a road that goes straight there, and I live in
the US,
so we use miles per hour, so let's say it's a 30 mile an hour trip, and it's, I
don't
know, something like 30 miles.
It'll make it nice and easy here, really far away for a grocery store, but it's
going
to, because it's 30 miles away, and I'm going 30 miles per hour, it's going to
take me
an entire hour to get there.
Versus what happens if there's a highway down here, and this highway allows me
to go, let's
say, 60 miles an hour.
So I can go twice as fast, and let's say it's a really short hop to get here
and to get
off the highway.
So it's going to take me 30 minutes to get there, even though I have to spend,
let's say, two
minutes getting under the highway and another three minutes getting off of the
highway,
when I add it all up, this took me 35 minutes, and this shortest path actually
still took
me 60 minutes.
So the 35 minute path is much faster simply because there was this super fast
highway
in between, and I was able to go twice as fast.
So we're going to apply the same concept to the network, because there's a lot
of sites
where we have an edge router, and I might need to get out to a particular cloud
service.
So we've got this service out here, regardless of what it is, and we'll talk
about all the
different cloud services that this benefits, but if there's this cloud service,
I might
think, okay, cool.
I've got a direct internet circuit here, and this cloud, sort of by the nature
of the cloud,
is on the internet, and so I'm just going to ride the direct internet path in
order
to get there.
And my users are back here, and they're, none the wiser to any of this, of
course.
So they're transacting or creating transactions with this cloud service going
back and forth,
and we might look at this and think nothing of it.
However, what if there was a faster way to access this cloud resource?
What if we have this SD-WAN environment, and this SD-WAN environment is
typically built
on pretty good, high bandwidth, low latency types of pathways, and this SD-WAN
path allows
me, in some fashion, to be able to get to the internet in such a way that it's
a much
faster trip going to out to this cloud service?
It doesn't feel particularly intuitive.
We're basically saying, hey, bring this client traffic in, and rather than send
it directly
out the internet pipe that I have attached to this very router, potentially, I
'm instead
going to send it through the wide area network, and through the network path
that I configure,
I end up going into the internet at some point and attaching to that cloud
service, or at
least connecting to that cloud service.
The theory here is what if this is actually faster, or potentially more
reliable?
Just depends on the situation and what exactly we are trying to achieve.
If this is lower latency or more reliable, fewer dropped packets, and of course
we'd
want to take this, but is this actually possible?
The answer is yes, because if it wasn't possible, then we probably wouldn't be
having this conversation.
So this is what on-ramp is all about.
Cisco has three primary on-ramp solutions that we're going to talk about.
We're going to talk about on-ramp for software as a service, on-ramp for multi-
cloud, and
the one that's probably the most fascinating of all is the on-ramp for co-
location.
If you think you know what that's about, based on the word co-location, I'd
encourage you
to stick around, because certainly the first time I learned about it wasn't
anything like
I thought it was actually designed to do, based simply on the word co-location.
So three primary products we're going to talk about.
You may notice that the traditional on-ramp service, which yes at this point,
SD-WAN is
old enough, we can call it a traditional service, but that on-ramp for IAS is
no longer listed
here primarily because it is part of the multi-cloud solution now.
Or we could argue that the IAS product evolved into the multi-cloud product,
but either way,
we're going to briefly address it during the multi-cloud conversation, but our
conversation
will primarily revolve around these three services.
So let's go ahead and dive into what exactly it is to run on-ramp for SaaS.
So first and foremost, what is software as a service?
Well the idea of software as a service requires a bit of a history lesson, and
we'll be very
brief with this.
But generally speaking, when we had a software creator, so a software developer
, they'd create
software, and we, as the corporation that wanted to deploy it, would deploy
that software
into our own data center, wherever our servers and storage lived.
And so our users who wanted to interact with this software would go to the data
center where
it lived on our servers.
So this is the traditional way that we would deploy software, this is known as
the on-prem
model.
Next, we have the concept of software as a service.
Now the software developer can say, "You know what we're going to do is we're
going
to deploy it onto our own servers in our own data centers."
Which is interesting, because now our users in this software as a service model
are going
to have to point to the developer's data center and have its transactions go
back and forth
in this fashion.
So why would we do software as a service?
Well first of all, we understand that there's no data center involved for me.
Notice, I don't have to worry about managing servers and storage for this
particular software,
at least.
And some software packages can require their own dedicated server and storage
infrastructure.
So I don't have to worry about that as a corporation.
It simplifies my data center operations, makes it easier to troubleshoot, and
at a minimum,
it's lower cost for me from a hardware perspective.
I don't need as much hardware in this situation.
And so the other fact of the matter is it is simple.
And simplicity can be the name of the game for many corporations.
There's plenty of complexity in the network these days, and complexity equals
money.
So we see we're trying to accomplish here is make our environment better.
However, we might say, "Oh great, I don't have to buy as much hardware."
And it's simpler.
I don't have to troubleshoot as much.
Maybe I don't need as much staff to support it.
The problem is this does typically cost more money in a monthly recurring
fashion.
So we call it a monthly recurring cost or a monthly recurring charge.
Meaning that over the course of time, I'll probably pay more to use the
software as a
service model.
However, it comes with some very important benefits.
For most organizations, it's worth it.
And for that matter, even though it might cost more, it's consistent.
I know I'm paying a subscription, X number of dollars for X number of users or
whatever
the situation is.
And so most organizations love when software as a service shows up.
From a home user perspective, I know that to do my taxes, I would always go out
and I
would buy tax software every single season.
And I'd bring it home and it would be on a CD or a DVD and I'd insert it into
my computer
and I'd install the software on my computer and then I would do my taxes.
But every single year, I had to install the new version and yeah, it was nice.
It would import my previous year's taxes.
So there's some benefits to that.
But nowadays, the way it works is it's all done in the cloud.
It's a software as a service solution.
So I don't have to install anything on my computer anymore.
I simply log in every year.
They've got all of my tax structures from the previous year.
And at that point, it's all done in the web browser versus before where it was
done in
the whatever software I installed.
And so we've got all kinds of examples these days, but generally speaking, if
we're not
installing something and we're pointing our web browser to it, that is usually
considered
to be a software as a service model.
And it's not that the software doesn't get installed because it does get
installed somewhere.
It gets installed in someone else's data center.
And so they're managing the servers, they're buying the storage.
And so that's why somebody needs to pay for it.
And I as the user end up paying for it over the course of time in most cases.
So this is the idea of software as a service.
So now let's talk about the on-ramp for software as a service portion because
that's really
what we're here to try to understand.
And what we're going to find is it's this model that's going to come into play
for us.
It's very important for us to understand some of these concepts where because
now we can
truly talk about the on-ramp portion.
So here's the idea.
Here's generally speaking what Cisco's trying to accomplish.
We understand with an SD-WAN world that oftentimes we're going to have an edge
device with many
different options upstream.
So I might have a circuit that goes to SD-WAN provider A and I might have a
circuit that
goes to SD-WAN provider B, which by the way might be an internet circuit.
And then I might also have a local internet circuit which is what my users are
supposed
to use.
And so I've got my network with my users.
And so we look at this situation and we might say, okay, where if the user
wants to go out
to a software as a service type of vendor type of deployment, where would we go
?
Well, the software as a service in order to be accessed by the rest of the
world must
be attached to the internet.
And so generally speaking, our path is going to go this way.
But what if this path is a 10 meg backup circuit or it's mostly used for the
sake of
browsing the internet, it's really not meant for company use.
And so the experience isn't very good.
Well SD-WAN offers us the ability to on-ramp or other words, to find that super
highway
that we talked about earlier and get there even faster.
For example, notice that one of these WAN circuits was an internet circuit.
And so we do technically have two different options to get to this SaaS
provider just
through native internet connections.
Yeah, I'm forming IP tech tunnels across this internet circuit because the WAN
portion
of my SD-WAN environment needs to be secure.
But I still have the ability to potentially for traffic through that cloud.
And maybe that is a more robust experience for my end users.
So what we're going to do is we are going to leverage our edge technology here,
or at
least the software running on the edge.
And it's going to perform sort of a knock on the door type of approach.
We're going to send out HTTP probes.
And we're going to evaluate what we see back based on this.
So in other words, we're going to ping the SaaS vendor on these different
connections.
And we're going to find out what's happening there.
What we're going to do is we're going to form a metric known as the quality of
experience.
And so we're going to abbreviate that as QOE.
Now formerly, this used to be known as Viptela, quality of experience, which
would be known
as VQOE.
So we might still see this in documents.
If you see the V in front of quality of experience, don't be surprised.
At this point, if we see a V in front of anything, we can pretty well assume
that if it doesn't
stand for virtual, it stands for Viptela.
And so SaaS Go is naturally doing away with VQOE in favor of just regular old Q
OE without
the Viptela there.
So the idea here is that we're going to rate these connections between zero and
10.
And so we might find that the classical internet circuit, or the one that we
would have just
been using otherwise, that this is rated a seven.
But this other path is rated an eight.
Now SaaS Go is going to determine this and we might want to dive into the weeds
as far
as, okay, but why is it rated this way or that way?
But in the end, the idea and the reason they're calling it a quality of
experience is that
regardless of the technical nitty gritty, the higher the number, the better the
experience
for the users.
So regardless of whether it's because it's lower latency or higher bandwidth or
fewer
drops, doesn't matter, it's a better experience for the users based on what
this edge device
is seeing.
So we already have the ability to differentiate between internet circuits, but
this can be
taken a step further, believe it or not.
There is a scenario where we might use our SD-WAN provider here.
And this is especially going to be relevant when we have a site that has a
single circuit.
There will be some locations that don't have internet circuits.
And so we might look at this and say, okay, so we've got maybe two WAN service
providers.
Maybe they're both MPLS.
We don't have internet here.
I just said single circuit, so let's actually do that as a single circuit.
So we've got one service provider here.
And what we're going to do is recognize that we actually might have a couple of
different
edge devices out here that have internet connections.
We want to figure out if we can hop across from one of these to the other.
So I've got my IP sectionals forms to each one, remember these are IP section
als.
And now I can figure out, hey, should I go this way to get to the internet or
should
I go this way to get to the internet?
And believe it or not, I can actually still compare these to a local internet
circuit.
So this isn't just a matter of saying, hey, I've only got one WAN circuit
versus multiple
WAN circuits versus no internet circuits.
It's really more a matter of finding out by evaluating all of my paths that are
available
through the internet, but especially number one, locally attached internet
circuits and
number two, what we refer to these here as regional hubs.
So I'm probably not going to want to look at every single edge device in my
network,
but I will look at the regional hubs here, that would be these routers, because
they
have internet circuits and then I can evaluate and track the quality of
experience, ID, or
metric that goes to each one.
So now I can say, yeah, my local internet circuit is again a seven, which doesn
't seem
that bad.
But if I take this path up here, this is actually a nine.
So weirdly again, here's my users, you'd think that I'd want to go right this
way to go to
the internet circuit, but according to my SD WAN environment, it actually would
be better
for me to go this way.
And maybe this one over here is a six and so it doesn't really matter.
But we see that we have many different options.
A lot of this does end up coming back to this original analogy, which is yes,
it feels weird
to go an extra mile or two or five or whatever it ends up being, but if it
takes less time,
if it's a better experience, then we would do it in a heartbeat.
And on ramp for software as a service is going to allow me to do that, thanks
to the edges
abilities to our ability to launch these HTTP probes to evaluate the different
connections
and the different options that we have and assign a metric to each one that
makes it
very simple for me to decide which path to take.
[BLANK_AUDIO]