Look, I know what you're thinking right now.
You're jumping into the next generation of networking, where
it's all about software-defined networking and automation,
and you may have a little hesitancy.
You may be thinking, I don't know anything
about software development.
And that's totally OK.
That's why you're here right now.
What we're doing in this skill is just setting the foundation
so that we can ease into bigger topics, like digging
into actual software-defined networking
platforms or automation.
So by the end of this Nugget, we'll
actually understand what software defined WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
actually understand what software defined
networking brings to the table and what
an API does in the first place.
That way, in the upcoming Nuggets,
we can start looking a little bit more
of the different categories of APIs and what types of data
they interact with.
Get ready.
We're going to have a lot of fun setting up this foundation
about what APIs do.
Let's get going.
Do you remember this slide from the previous skill,
when we were talking about the architecture of an application?
If you don't, that's OK.
We're going to set it up again really briefly.
When you are interacting with f website that might actually WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
When you are interacting with f website that might actually
be a website that's running an application,
here's how it's structured.
You log into the website, and this is all you really see.
You see the web front end--
which is what we'll call it--
and your web browser downloads an HTML document,
it downloads a CSS document, and it downloads a JavaScript
document.
And your web browser is designed to download these documents
and turn them into a pretty website
that you can interact with.
So your front end-- you see the pretty website that's WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So your front end-- you see the pretty website that's
got the design, and the art, and the pictures,
and maybe some products that you want to buy,
and that's all you ever see.
But maybe on that website, there's
also some fields to fill out.
Maybe there's something like a first name, and a last name,
and a Sign Up button.
So you fill out these fields and you click the Sign Up button.
What happens then?
You see, what you've done here is you've just created data,
like my name here and my last name here,
and you've instructed that website
to do something with that data, to process that data. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
to do something with that data, to process that data.
And this is where the application website
hands the data off to other resources.
Behind the scenes, what's really going on
is that website will transmit this form data here
to a back-end server.
This back-end server will validate, OK,
we've got a valid first name and a valid last name.
And if it's coded correctly, it will
make sure it's not trying to run a SQL
injection or a cross-site scripting injection,
and then it'll do something with that information. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and then it'll do something with that information.
Maybe it sends it off to a customer support team.
Maybe it sends it to a analytics platform, where
they can analyze sign-up data.
Or maybe it forwards it straight into a database, where it can
store, historically, that data.
Not only will it store things like my first name
and last name, but it may store, what website did I come from,
or what time did I click the Sign Up button?
The big thing that now we're setting up
is, how do each of these individual unique servers
communicate to each other?
Servers and applications send data WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Servers and applications send data
to each other using what's called an API.
And that's what we're trying to set up in this exact Nugget is,
what does an API really do, and how does it fit in
with a networking landscape?
What does software-defined networking do,
and how does it do it?
It all comes back to APIs.
Let's clear the screen one more time
and talk about how an API differs a little bit from what
we just did.
You see, again, when we opened up our browser WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
You see, again, when we opened up our browser
and we typed in the URL to go to,
what really happened here is we got
sent through the internet to a web server that holds nothing
more than HTML documents, CSS documents,
and JavaScript documents.
So when we access that website-- we'll just call it mysite.com--
what we're really doing is the web browser
is just going to the server and downloading these documents
onto our local computer.
So our browser loads these documents
and turns them into a pretty website.
That's the gist of how web development works. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
That's the gist of how web development works.
Obviously, there's some more complicated aspects to it,
but that's the gist of it.
That's the highlights of it.
An API does something very, very similar.
Instead of us, a human, interacting with mysite.com
now, now we're going to tell an application
to interact with mysite.com.
It'll still leverage HTTP as the protocol,
but instead of returning HTML, or CSS,
or JavaScript documents, what it actually
returns are documents that contain raw data. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
returns are documents that contain raw data.
And these documents come in the shape of XML or JSON.
You see, applications don't care for an HTML, or CSS,
or JavaScript document because it doesn't need to be pretty.
It doesn't need to be formatted for human eyes.
The application just wants raw data
that it could easily comb through,
and XML and JSON are very easy for applications to comb
through.
So instead of returning these HTML, CSS,
or JavaScript documents, the API may go straight WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
or JavaScript documents, the API may go straight
to the database, grab the data out of it
that it wants, and returns that data in the form of an XML
or JSON document.
From there, my application can do whatever
it wants to with that data.
It can make decisions on how to use it.
And the key thing that we're setting up here
is this is how applications communicate to each other.
I can say with an extremely high degree of certainty
that, if you have a software development
department within your organization,
they are developing or working with APIs regularly. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
they are developing or working with APIs regularly.
In fact, they may be developing scheduled tasks that
tell your own application to reach out to some API
on the internet and grab data on a schedule.
Maybe it's every day.
Maybe it's every hour.
So this is all well and good.
Up until this point, we've talked a lot about websites,
but we're not here to talk about app development, are we?
We're here to talk about network automation
and software-defined networking.
Software-defined networking is the new era
that we're in, so it's time to bring up a new diagram
and talk about network automation,
software-defined networking, and where APIs fit in with that. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
software-defined networking, and where APIs fit in with that.
Cisco has made it a point to say that just about every platform
that they produce now must have some form of API,
some way to interact with it programmatically.
So just about every device that they're rolling out
these days has an API sitting on it,
waiting for you to interact with.
So you could theoretically write an application
that pulls data straight out of these devices.
I'm also going to throw the ASA line of products WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I'm also going to throw the ASA line of products
in here too, because they also have an API.
And then, of course, we can interact directly
with the Firepower Management Center.
So keeping that little Nugget in mind,
this is where we're going to talk
about what software-defined networking is really
doing for us.
In the traditional way of working with network devices--
let's say we deployed these three Firepower threat
devices, and then a couple Firepower devices,
maybe some ASAs--
the traditional way was we would deploy this device,
we would plug a console cable in,
and we'd start typing on the command line programming. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and we'd start typing on the command line programming.
Or maybe we did it from a web browser,
or ASDM and the old Java days, or things like that.
The point is we configured these devices one at a time,
and in large deployments, that took a lot more time to do.
But then they introduced this concept
of software-defined networking controllers.
Now we have one place to log in and see the entire network.
And as long as our devices, like these Firepower threat devices
here, know where this controller is--
they've been onboard it into that controller-- we can WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
they've been onboard it into that controller-- we can
configure the batch of them, or view or monitor
the batch of them from this one login.
So again, here's you.
Instead of going to your shopping website,
now we're going to the Firepower Management Center website.
And under the hood, you now have an idea
of this three-tier application that's
actually what's running on Firepower Management Center.
You see the web front end, but then there's
going to be an application and database behind the scenes.
And what's really going on behind the scenes WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And what's really going on behind the scenes
is Firepower Management Center is an application that
is programmatically communicating
to all of our other devices.
So using APIs, Firepower Management Center
is sending requests for information,
or data, or configuration changes to the Firepower threat
defense device, or the ASA, or the Firepower devices,
and data is being streamed back in to Firepower Management
Center, where it's then housed in a database. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Center, where it's then housed in a database.
So thanks to automation and the simplicity
of software-defined networking, we, the end user,
only have to interact with one pane of glass
into our network with one networking device.
That's the controller.
And from there, the controller can communicate
to all the different network devices to gather information
out of it.
Now, here's the real kicker--
APIs come in many different shapes and sizes.
Most APIs communicate over HTTP--
or really, HTTPS for security's sake, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
or really, HTTPS for security's sake,
to make sure the data is encrypted
as it flows across the wire.
Some older APIs use a variant called SOAP,
and you don't need to really bother yourself
too much with SOAP APIs.
Just know that it exists and it's
really prevalent in Cisco's collaboration platform.
But in recent history-- and recent as the last 10 years--
APIs over HTTP have evolved to leverage all of the options
that HTTP can really give it, and these are often
called REST APIs.
The concept with a REST API is we're just WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
The concept with a REST API is we're just
going to be leveraging all of the different components
that the HTTP protocol offers for us
so that we can interact programmatically
with either our controller or our network devices.
So the first type of API that you should know about
is really going to be APIs that operate over HTTPS.
And you really want to focus in on REST API.
When you're creating applications
and you're creating code, your preferred method of doing this
is probably going to be using REST API first. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
is probably going to be using REST API first.
But at the end of the day, the purpose of an API
is just for applications to exchange data back and forth.
So you could make a pretty strong argument
that SNMP is a kind of API, or NetFlow is a kind of API.
There are also protocols designed specifically
for network automation, like NETCONF.
NETCONF operates using SSH as a transport
and it sends XML requests, and commands, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and it sends XML requests, and commands,
and data back and forth to each other.
NETCONF is an extremely popular network automation programming
interface because it's been around for a long time--
since 2006.
But in recent history, network automation developers
are starting to shift more towards the REST API
side of things, but leveraging all of the things that
made NETCONF good.
So they're creating RESTCONF.
Again, this is a protocol designed specifically
for network automation that's leveraging REST APIs. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
for network automation that's leveraging REST APIs.
So we're talking about HTTP and HTTPS again.
So if we're looking specifically at the security platform
and the things that are on the screen here, of course,
Firepower Management Center as well as
many of our network devices come with the human-readable front
end that you're used to seeing, which
is using HTML, CSS, and JavaScript.
But from an application programming standpoint,
these all leverage REST APIs.
So our application can leverage the HTTP protocol, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So our application can leverage the HTTP protocol,
requesting data or requesting that a configuration be
changed, and responses are sent back typically
in the JSON format.
And the same thing goes with communications
between Firepower Management Center and our network devices.
So when we make a change maybe from the front end,
when we say we want all of these devices to have a new policy,
Firepower Management Center uses the APIs to push these policies
out, and these devices respond back
with OK response messages or any data that's WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
with OK response messages or any data that's
pertinent to that chain.
Now, the last type of API that I'm going to be talking about
is another one that we're going to be talking about in depth
towards the end of this course, and that
comes down to telemetry.
This is another thing that APIs really
bring to the table for us.
Remember, again, Firepower Management Center's
going to be storing all sorts of data and statistics
coming from these devices.
Well, how does that really work?
Under the hood, Firepower Management Center
sets up what's called subscriptions.
It says, I want to know about all of the times
that a configuration changes, or I want to know about all WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that a configuration changes, or I want to know about all
of the times that your CPU threshold is overused,
or anything like that.
And this data will automatically be streamed back
to Firepower Management Center, which stores it in a database.
And that, at the end of the day, is the point
of streaming telemetry.
It's just to get a constant feed of data
back to a centralized database so that we could view
the whole network in one place.
So this sets up the fundamentals of what
software-defined networking really does
and how they leverage APIs for communicating WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and how they leverage APIs for communicating
from one central place to all of the different nodes
around our environment.
So in the next couple Nuggets, we're
going to be talking more about the directions
or the different types of APIs that we're
going to be interacting with.
That's been API Fundamentals.
I hope this has been informative for you,
and I'd like to thank you for viewing.