Manage the full API lifecycle with Apigee Edge API platform (Google Cloud Next ’17)

Manage the full API lifecycle with Apigee Edge API platform (Google Cloud Next ’17)

afternoon, everybody. How are you doing? AUDIENCE: Good. PRITHPAL BHOGILL: That’s it? AUDIENCE: [LAUGHTER] PRITHPAL BHOGILL: Let’s
try one more time. How are you doing? AUDIENCE: Good! PRITHPAL BHOGILL:
Excellent, much better. So I realize we’re sitting in
between you and your beers, or whatever cocktail
that you may enjoy. We’re going to try
and keep this session interactive and interesting. My name is Prithpal Bhogill. I’m part of the product team– the Apigee product team
within the Google Cloud team. And I’m also going to be
joined by Greg Brail who is the Principal Software
Engineer within the Apigee team as well. So if you’re here for
learning about how you can manage APIs and
focus on the full lifecycle, then you are in
the right session. Pat on your back if you
made it to the right room. You have heard a lot
about APIs today. In the morning keynote you
heard many APIs being discussed, some products being shown. We’re going to try and
take you to a journey on, what does the API
lifecycle look like? As we see many of our customers
adopting APIs and using that as a way to transact digitally
with many of the businesses– many of the partners
and employees and external entities– we’re going to walk you through
the role of the API team. This is a team who
is traditionally responsible for working,
standing up APIs, securing them, so on and so forth. So today is going to be a
very interactive session. We’re going to duel back and
forth between slides and demos to give you a taste of how
that experience looks like. Why APIs? When you hear about things
such as digital transformation it essentially means many
modern enterprises today are transacting their
business through APIs. So all the core capabilities
that have been locked in some systems or records–
such as ERP systems– some of the systems
which are home grown are now unlocked as APIs
in this modern world. Which means you
can take those APIs and not only create some
excellent productivity applications internally, you can
take them out to your partners and build this whole ecosystem. In the morning in the keynote– if some of you guys got
a chance to attend that– the different kinds of
ecosystems, partners, employees, and then
even the outside world to the industry and
then external entities. APIs are becoming more and more
central to every organization that is trying to participate
in the digital world. We take a slightly
opinionated view about APIs, and we start with what we call
as the digital value chain. It’s actually a very simple
concept if you think about it. At the end of the
day, all what matters is the entity to your
left or my right, which is the customer
or the end user. It’s all about delivering
delightful and connected experiences to those end
users through an app. An app can be of any kind. It could be a mobile app. It could be an
app which is built in the web or even a setup box. Well, there are developers
who build those apps, right? And they build those apps
using well curated APIs which are managed by an API team. And this API team
comprises of API developers who will use a platform
such as Apigee Edge to manage, secure,
publish to the APIs. And essentially the
API layer really sits on top of any back-end
system that you may have. It could be something which
is already service enabled. It could be an old system
which has some SOAP-based API, perhaps. Or perhaps there’s
some legacy systems which are unlocked using some
kind of a middleware solution. So we’re going to examine
what the data value chain is and how you can essentially
use these core constructs to do something very simple. It’s all about
ensuring that you have massive adoption of these APIs. As you start in
a digital journey and start to transact more
and more through APIs, adoption is key. It’s only as good as
people using your APIs that they are going to start
giving you the benefits that they promise. It’s also about scale. You need to be able to
rely on a platform that can support massive
scale, and we’re talking about internal scales. As a platform, Apigee Edge
supports billions of API calls in a day in the Cloud. And we have several
of our customers who are actually supporting
the exact same capacity in their own data centers today. It’s also about control. Ensuring that people have
this awesome experience comes at a cost. You want to ensure
that if APIs are the way you’re
transacting your business, it’s done in a
careful, curated way. You have a lot of
security around ensuring that only the people,
or the entities, or the apps, who should get
access to those APIs do so. And in the end, all the tools
and the platform capabilities really put a focus on
trying to give you all that at a very fast pace or agility. I’m going to turn it over
to Greg for this piece. He’s going to walk us
through what the Apigee Edge platform is all about. And then both him and me are
going to duel back and forth in showing you through a live
demo of the journey of an API developer and how they use
a platform to build APIs. Greg? GREG BRAIL: Excellent. Hey, I’m Greg. I’m going to be talking a little
bit about the Apigee platform and a little bit about
what we actually do here. So people always ask,
what does Apigee do? If we looked at that
digital value chain, there were really two
things that were happening. We were connecting
the developers– the people who build
apps that use APIs– with the API team. The people who actually
create the APIs that they use. And for that we
have to have things like developer
portals, documentation, self-service onboarding
tools, so that a developer can click on a button and get
the security credentials they need to make
API calls right away. There’s also a
technical connection where we’re doing things like
adding security to API calls, doing rate limiting,
caching, transforming APIs from one format to another. The Apigee Edge product is
responsible for doing really both of those things. And if we look at the
components of the product, there are a couple
of different pieces. Down at the bottom is
what I’m talking about. Between the application
and the API itself we have a set of
runtime services, and that’s where we
can insert policies. And Prithpal is
going to show you how we create those policies,
and what they can do. And those policies can
do all sorts of things, like I said, security,
rate limiting. You’ll get the
whole story there. And then on top
there are a bunch of services that enable that. So for instance, there’s
a management component that is responsible and
supplies both a user interface and an API for manipulating
all of these components. Programming the proxies,
configuring the developers and the applications,
and everything that Prithpal is
going to do in the UI has an associated API as well. There are also a set
of developer services. Those are the developer
portals, and the tools that we can use in
order to construct a web presence for our API, so a
developer can really connect and learn how to use the API. And there are a set
of analytics services that are gathering metadata
about all of the API traffic and presenting it
in different ways so that you can report on
it, create custom reports, and see all sorts of
information about how the API is being used. Now, Apigee Edge is a
product for all this. Companies such as Google
have API management systems that they built themselves
for their own APIs. What Apigee Edge
really is is a product that allows anybody to
create the API management system that they
need for their API and that fits in
with the requirements of their enterprise. Now, I don’t know if any of you
are Apigee customers already, but I wanted to talk a
little bit about actually how the product is deployed. The entire product we
described there actually can run in a couple of
different form factors. We deliver it as a service. It’s available as a service,
which means everything you see in the demo today– it’s all multitenant,
self-service Cloud App just as you come to expect from
the Google Cloud Platform– where Apigee is actually
sitting in between API calls being made from
the client to the server, and it’s actually the runtime
is going through our Cloud. The entire product
is also available for on-premises deployment. So we have a number of
customers– typically large customers– who
have lots of data centers. Because contrary to what
we might say sometimes, there’s still a lot of data
centers out there in the world. And customers often want to have
their API, and all of their API traffic, and all of
the management of it controlled by their own software
running in their own data center. And finally there’s
a hybrid model. And I’m going to get
to that a little bit, because that’s some very
interesting stuff that is starting to emerge
that is starting to meet our customers where
they really want to be. If you look at the traditional
way to use Apigee– sort of a big, big product
that sits in the middle. So if we look on the top, you
may have mobile apps and web apps that are making API calls
from the internet to back-ends that are down on the bottom
within an enterprise network. And in using the Apigee
Edge as a service, typically Apigee is running
in the internet. The API traffic is going to
Apigee somewhere in the Cloud, and it is actually connecting
back to the back-end. And interestingly enough,
the runtime component of Apigee Edge can run
in the Google Cloud. It can also run on
the Amazon Cloud. Because the truth is we
have a lot of customers out there whose API back-ends
are already in Amazon. And we’re committed
to making sure that that runtime is available
in both of those locations, so that people can choose and
they can put their API proxies where they actually
need them to be based on the geography
of their actual network. But we also offer
a hybrid option. And that hybrid option allows
you to have the API gateway– the thing that proxies
the traffic located wherever you want– without having the rest
of Apigee come with it. So things like analytics and
management of the API stuff come as a service,
whereas the gateway itself becomes something that you can
deploy on your own network. One of the things
we’re doing this week is we’re actually introducing a
new option for the Apigee Edge product called Edge Hybrid. And we’re actually announcing
an early access program that we’re signing up selected
customers for this week. And what that’s
allowing us to do is allowing us to mix
and match and have sort of the best of
both of these worlds. Where the runtime components,
the analytics components, and the control components stay
as a service within Apigee, but the gateway itself,
the proxies, the traffic can go anywhere. And we’re introducing a
new open source component that we’re calling APID. And one of the
things that APID does is it sort of acts as an
API for API management. So it offers services for
things like verifying API keys, computing distributed
quota values, and gathering API analytics. And then we can have
a variety of gateways that actually run in
your own data center, or inside a
Kubernetes container, or inside Pivotal Cloud
Foundry, or wherever you need them to be
that can then use APID to supply those services. And in the end,
we’re giving people a very flexible
architecture where we’re going to give them
very good performance and a lot of robustness. Because the truth is that
there are a lot of different places where APIs need to run. API don’t just run
in big data centers. They don’t just run
on the Google Cloud. Increasingly, APIs run
on the backs of stores. APIs run in airports. There are all kinds of
places where these APIs back-ends live,
and we want to be able to put a component of
the API management system in all those places. Now I want to get a
little bit to talking about the lifecycle on the
demo we’re going to talk about. We think really that all APIs
go through a very similar lifecycle like this. We’re going to start at
the top with API design. But we’re going to move
on to how you actually design your API and
how you share that API design with others. How you actually turn
that API into something that’s on the internet. How you add layers of
security to your API using industry standards. How you publish your API to
create a developer portal, and a web presence
developers can use to sign up for your API. What to do if your API
gets a lot of traffic. How is it going to scale? How are we going to
monitor what’s going on and get analytics, so
we can understand how the API is going to be used? And there are lots and lots
of ways to monetize APIs. And one of the
ways is, of course, to charge for API calls. And if that’s an option that
works for your business, that’s something we’re
going to talk about as well. We’re going to start
that, and we’re going to trade off a
little bit on the demo and switch from one to
another, but we’re not going to switch just yet. I haven’t said the magic word. So let’s start with design. And Prithpal is going to be
the person who does this, and I’m going to ask
him some questions. I’m an API developer. I’ve heard of swagger. And I hear about
something called Open API, which sounds
like a less exciting way to say swagger. But as I understand
it, I can design and I can describe
my API in Open API. And if I do that, there’s
all kinds of neat things I can do to generate
cool documentation and to share my
API documentation with other people. Can you show us a little
bit how we can do that? PRITHPAL BHOGILL: Absolutely. You’re right. Open API is a great
way to be able to share what the API does. It’s an excellent
contract which can be used to not only create
API but also share that across different developers,
so they have a common sense of what an API looks like. We’re on the demo
screen out here. What you see out here is
I’m logged into Apigee Edge. This is the Apigee
Edge Cloud version. It looks exactly the
same like when you would deploy it on-premises. I’m actually leveraging a brand
new Apigee Edge experience. This is a user
interface we actually released just about
a few months back, and it is centered
around the API lifecycle. So in this case,
I’ll do a little bit of level setting here. I’m connected to
the demo file ORG. Think about ORG as a
short for an organization. And it’s the container where I
as a business unit, or a team, or a company if it is small
enough, will build all my APIs and add some policies. The very first thing
we’re going to do is start off with taking a spec. In this case, I’m going
to take the liberty of leveraging a spec that is
called Open API for hotels. It’s a very simple spec
which is sitting somewhere in the internet. In this case, it happens
to be just a simple gist on our GitHub account. So let’s go to the
Apigee Edge screen. GREG BRAIL: So that spec, that
yaml, was the design of my API. So as a developer I might
use a tool to generate it, or I might just typie,
type, type, right? PRITHPAL BHOGILL: Exactly. It all starts from
the spec editor. So I’m in the tool, I
click on the spec icon, and let’s go import the spec. I’m just going to paste the
URL that I just picked up from there and say, import. And if viewing the
demo-gods are with us today, it should–
in a few seconds– actually show you how
the hotel’s Open API spec looks like. So Greg, as you
can see out here it spits out some very important
information out there, such as on the left hand side
talks about what the host name is, the base path is. But more importantly,
this is information that gets synchronized
left to right. Everything you want to know– GREG BRAIL: Right. So on the right I have
a nicely formatted set of docs for my API. PRITHPAL BHOGILL: Exactly. And then more
importantly, if you now start examining
this simple API doc, it very clearly describes
what this API should be doing. In this case, we have
certain resources which have been declared
out here, such as how do I query a specific hotel? So you have different
kinds of options provided to you out there. Options to update hotels. In this case, we’re going to
use the backdrop of a hotel as an example. And then you also have
the ability for you to actually get a list
of all the hotels. So, Greg, as we just
were discussing, the Open API spec
gives you the ability to communicate your intent. And in this case,
the Open API editor– or Open API, it used to
be only known as swagger– is integrated right
into the product. Once you have
imported the spec, you can actually collaborate
with other API developers in the team, so they can
edit, make some mods, perhaps add some changes. And then you can take it to the
next step of that publishing or to actually creating an API. GREG BRAIL: OK. Cool. And I should point out that
Open API is an open standard. It’s controlled by the
Open API foundation. The Version 2.0 is the
version of the spec that we’re looking at here. There’s a version 3.0
that’s in the works and about to be published
that takes into consideration a lot of the inputs
people have had. But we’ve been working with Open
API for a couple of years now. And we’ve found that it’s
become the de facto standard, and essentially the
most popular format out there for a free
API specification. There are some cool
things you can do with it. You can even generate as
SDKs for various languages from the Open API spec, which
is sometimes something that’s very handy to be able to do. Let’s go back to the
slides for a sec. And so we talked a little bit
about the spec and what open is and how it is. So once I have a spec,
now what do I do? How do I actually turn this–
now, clearly, I’m a developer. I probably wrote some
node code or something to implement my API. Maybe I wrote some node
code that uses Postgres, and I deployed it to
Google Cloud or wherever. It doesn’t really matter
where I deploy it. But I now want to have all
the API management goodness, and all the service ability
of Apigee around my API. So how do I do that? PRITHPAL BHOGILL: Yeah, so
that that’s a great point. Now you’re going to
focus on– great, I have some design
using an Open API spec. How do I take it to the next
level of actually building an API proxy. So let’s switch over
to the demo, please. All right, so I have an API. Using a simple click, I can
click on the Generate API Proxy button. I can give it the base path. Let’s call it, v1/reservations. And again, all
I’m doing out here is it has picked up all that
information from the Open API spec. In this wizard, I’m just
making a few changes, because I would like
for the API proxy to be deployed in a
very specific way. You can see there’s
a back-end endpoint. This actually happens to be
an existing API endpoint. So if I was to go out
here and query this, this is exactly the back-end
API that Greg was just talking about. This is running
somewhere in the Cloud. It could be the Google Cloud. It could be any
other data center. It doesn’t really matter. This is the endpoint
that we’re going to create a proxy in
front of, and then we’ll use the API magic to add a
bunch of different things. So I go back out here. Click the Next button. And fair enough,
the API proxy wizard had actually picked up all the
different resources which was specified in the Open API doc. And I have the
option to say, great, I’m only going to
do just retrieving all the hotels for right now. GREG BRAIL: So we’re just going
to do the most basic API, which is get/hotels. PRITHPAL BHOGILL: Exactly. GREG BRAIL: Good place to start. PRITHPAL BHOGILL: Something
very, very simple. And in this case, I’m going to
add some security a little bit later on in the phase. But for right now I just want
to keep it at a simple path through proxy. And oh, by the way, by
even making a simple path through proxy, you can
get a lot of visibility and analytics on API usage. So let’s go ahead
and click next here. It gives me the
ability to decide where I would like to deploy the API. So let’s just go with
all the default settings and hit build and deploy. So at this point in time, it
has built a very simple API. And I have a brand
new endpoint, which is going to be now used to start
sharing with the outside world. So in this case– GREG BRAIL: So now instead of
sending my API calls directly to my back-end, I
send them to Apigee. PRITHPAL BHOGILL: Exactly. Here’s the Apigee
endpoint, and I’m just using a simple REST
client, in this case it happens to be Postman. And when I call
this, fair enough, it gives me the
exact same result back from the back-end API. So at this point in time,
we’ve gone through two steps. We have an Open API spec doc,
and we’ve used the proxy editor to be able to generate
an API proxy which just points to that. Greg, do you see something
missing out here perhaps? If I was to share this API
endpoint with someone else, could someone perhaps abuse it? GREG BRAIL: Yeah. I also want it to be HTTPS, but
I know that’s an easy option. [LAUGHS] But, yes. What’s to stop someone from just
watching this demo on YouTube– it’s going to be
on YouTube, right? And just trying to hit that
thing 1,000 times a second and trying to screw up our demo? PRITHPAL BHOGILL: Yeah. So that’s a great point. How do you ensure you can keep
things in checks and balances, right? So there are a variety
of different ways. So in this case, what I
would like to show you is, great, I have an API, and
this is where the API proxy magic starts. So in this case, I’ve opened
up an API proxy editor. This is where I, as the API
developer, or the API team, has the ability to put in a
lot of different controls. And you put in those controls
using what we call as, API policies. So I click on this
plus step icon, and it brings up the 30
different out of the box policies that we have to do a
variety of different things. We have some traffic
management policies, security– some of this we’re going to
be taking a look at later on– mediation. And then more importantly,
you can extend the platform by using some of the
extension policies. So you could literally use
things like Java, JavaScript, or Python to pretty much
author your own policy and share it with
the rest of the team. In this case, I will use
something as simple as Spike Arrest policy. The Spike Arrest policy– think of this as a system-wide
policy which can make sure that only a specific amount
of transactions per second, or transactional per minute,
whatever that rate happens to be, it can control
that so that none of your back-end
systems crash and burn. As we know, that back-end
API is running somewhere. It’s either in the Cloud,
or it’s running on-premises, and it has some finite capacity. So in this case, I can make
those quick changes using some configuration options. In this case, for the
purpose of the demo, I’m just changing it
to three per minute. What this means is do not
allow any number of API calls, or only allow three
calls per minute. Just a very simple policy
that I’ve added out here. And at this point in
time, I would also like to call out the trace tool. For those who attended
the keynote in the morning may have seen the trace tool. It was flashed briefly. The trace tool gives a
very powerful mechanism for the API developer. As I’m building
out API proxies, it gives me some vital checkpoints
and information to make sure– are the policies which you’ve
added in working as expected? So think about this as
a web-based testing tool throughout my API
development process. So I’ll just leave
the trace session on. I’ll go back to my client,
and I will call this API. And when I do this, you can see
that there was a trace which was recorded here. I can hover over
some of those things and gather some
wider information. In this case, it
tells me exactly what was received from the user. I can hover over–
in this case, you can see the Spike Arrest policy
barely took even a millisecond. So many of these
policies have been very optimized to ensure
neural network level latency. Let’s now try and
pretend that someone is trying to call the APIs
more than they should. And let’s see what
the API platform does. So when I tried to
hit it a few times, right away the Spike
Arrest policy kicks in. It was set to three per minute. And in this case, it
calculates they’re only going to allow three
transactions per minute thereby protecting your back-end APIs. Over to you, Greg. GREG BRAIL: Thanks. So as you can see–
just taking a break here from trying to be scripted–
what Prithpal has done is he’s shown that we can
create a proxy for an API and we can add policies. Now, we don’t have
unlimited time, so you might ask
questions like, can I customize the response
that comes back from this Spike Arrest policy? Can I have different
Spike Arrest limits for different types of APIs? Can I have TLS turned
on and required? Can I transform the API response
like we showed on the demo this morning? And the answer is, yes, you
can do all those things. This product has been around
for a couple of years. We have a lot of large
enterprise customers who drive a lot of sometimes
obscure requirements into it. For the purposes
of the demo, we’re not going to show every
single thing we could possibly do with the product, but we’re
trying to give you an idea here. But let’s go back to
the slides for a sec. So basically what we’ve
done is we’ve shown, hey, using the Apigee Edge we can
now create a proxy for the API where we can insert policies. So now instead of going directly
to my back-end and then going to Apigee– and it’s pretty easy to
insert some basic policies like a Spike Arrest to give
a basic level of quality of service to my API. But of course, one of the things
I would think is, gee, great. You got a Spike Arrest. Now that people
watching on YouTube can’t really mess things up, but
my API still has no security. And that’s no good. I’ve read about OAuth. I understand that OAuth is
one of the de facto standards for API authentication. How can I start to add some
of those things to my API without having to learn all
the complexities of the spec and programming all myself? PRITHPAL BHOGILL: Now,
that’s a great point, Greg. In fact, many customers
that we talked to, OAuth 2.0 is a very popular
API security standard. So in this segment, we’re going
to take a look at how exactly we now take this API
and actually protect it using an OAuth policy. Let’s switch to
the demo, please? Let’s carry this thing
a little bit forward. I’m going to create and add a
very simple OAuth 2.0 policy. When I add this,
you can see that I’m trying to use the
VarifyAccessToken method. And the VarifyAccessToken
method within this OAuth policy is actually going to ensure
that this API, whenever invoked, is presented with a
valid OAuth token. Just for kicks, I’ll go
back to my Postman client and hit a send request. And right away you can
see that it points out I need a valid token. So how do we go about
getting this token? One of the key parts
of the platform is the notion of
an OAuth server. So the Apigee Edge actually
has a built in OAuth server which can
mint tokens, and we support a variety of different
kinds of OAuth flows. We have the standard two-legged
and three-legged OAuth flows out of the box. And because the platform
is customizable, you can actually support
some other flows as well. Whether Apigee is the platform
that does the OAuth dance itself, or it integrates– which
we have in the past with many different identity and
access management systems– it can control that. Mint tokens, take some
other systems tokens, and enforce that,
and all that stuff. In this case, in order
to actually show you how this would work, I’m going
to introduce a new concept, and that’s of an API product. So what’s an API product? An API product is actually the
way you would want to expose your capabilities– which
are nothing but APIs– in different shapes
and sizes to consumers. So you could think
about a strategy where I could take
three APIs and only give read only access through
what we call an API product. So an API product– and I’ll build something
out here called Hotels Gold. And you can assign
some quotas out here. In this case, let’s
say 100 per minute. And I’m going to pick the
API proxy that we just built, which is Hotels. In this API product
definition, I can add a bunch of
different API proxies. And I can also limit them
by perhaps all of these APIs only have get access. GREG BRAIL: So you can limit
what I can do with the API, as well as which
parts of the API I can call, but also
what I can with it. OK. PRITHPAL BHOGILL: Exactly. And one of the other things I
could do is the exact same API combination– or
perhaps a separate one– I could perhaps make a
hotel’s platinum product. In which case– GREG BRAIL: For free? PRITHPAL BHOGILL: Yes. GREG BRAIL: Right. PRITHPAL BHOGILL: In which case,
give them access to more APIs and perhaps let you do more
with those APIs itself, and perhaps up your bandwidth
to a 1,000 times a minute. So let’s go ahead and
save this API product. Great. So this is there when we
talk about the API team, you also have collaboration
with not only the API developer but the API product manager. If you think about data as
business and APIs as products, that’s exactly what we mean. Now you can bundle these
API and then offer them to the outside world. So great, I have
a product, but I need to be able to showcase
some level of security access. So in this case, I’m going to
introduce a concept of an app. Think about an app that has the
ability to actually generate some API keys. So in this case, I’m
going to very quickly call this the Hotels Gold app,
pick a developer here. And in this case, I’m going to
pick the Hotels Gold product and hit Save. So all what I’ve done
so far is saying, great, I have an API product
called Hotels. Now let me generate an
app called Hotels app. This is the app which has an
identifier key ID and a secret which you would share with
the app developer who’s going to consume the API. This is where the
consumption angle comes in. So you can pretend
you have 10 partners. Each one of them may
have a separate app. Why would you do that? You would do that so you
can track them separately, you can report usage,
and as Greg mentioned, you can do some
pretty exotic things. You could have some partners
who are subscribed to the Gold product and have access to
lesser parts of the API, part of the lower quota. Or you can create apps
that give access to, let’s say, the Hotel’s
Platinum product, which give you more
access to the same APIs and additional stuff for
some of the other APIs. Once I have the app– let’s click on this– I have what we call
as a key and secret. So what I’m going to
do at this point is– as I mentioned Apigee Edge also
has a full blown OAuth provider in the platform. I’m actually going to use a
pre-configured token endpoint, which is enabled by default in
any OAuth that you provision. And I’m going to specify
the client ID and the client secret. So what I’m really
doing out here is I’m mimicking that I am
an external client, which you have configured using an app. And someone has shared the
app key and secret with me. Traditionally, the sharing
of the app key and secret essentially happens
through a developer portal. That’s on the consumption side. So I call this. And I’m using the
client credentials grant type, which may be very familiar
to some of the folks who are perhaps API developers already. When I make a request out here,
it gives me an access token. So I now have an access token
which can be used securely to access the API. This access token
could be timed. It can also be
scoped, where in it can give access for
different parts of the API within the product. At the product level
you can actually configure what kind of
scopes it allows access to. Let’s take this access token. We’ll go back to
the Hotels API proxy and now add an
authorization header here. And the exact same token
that was just minted, we’ll place it in the
authorization header and now make a request– whoops. GREG BRAIL: Maybe we
didn’t cut and paste right. PRITHPAL BHOGILL: Let me– oh. GREG BRAIL: That’s your
client ID, I think. PRITHPAL BHOGILL: I think I
may have the wrong client ID. Let’s go take a look
here and make sure. This is a live demo, guys. GREG BRAIL: [LAUGHS]
Yeah, that’s right. PRITHPAL BHOGILL: OK. Let’s see this and
get it out here. Oh. I know what the problem is,
and I know how to fix it. GREG BRAIL: It’s a demo. Oh, we didn’t set
up– did we not? PRITHPAL BHOGILL: No. There’s one thing which
we actually skipped over, and that was this
back-end system that I’m hitting actually has
its own security mechanism. GREG BRAIL: Oh. PRITHPAL BHOGILL: And this
is all writing the header, so let’s show them– GREG BRAIL: Because we’re
sending your token to GitHub. PRITHPAL BHOGILL: Exactly. Let’s show them how
we can actually use– GREG BRAIL: Yeah, let’s
take that access token out. PRITHPAL BHOGILL: And
let’s remove that token. So here’s another
key thing out here. As you’re minting
these tokens, they may be back-end
systems, which happen to be in this case, which is
sensitive to an OAuth header. You might want to
remove or disable that OAuth header from here. So in this case,
let’s go and let’s remove the authorization header. This wasn’t scripted by the
way, just for the record. That’s a live demo. So let’s go remove the
authorization header from here. So again, using simple policies
we can plug this thing in. And now, hopefully, this
thing will let me through. GREG BRAIL: So if you weren’t
so quick on the uptake, we would have used the trace
to figure what was going on. PRITHPAL BHOGILL: Exactly. GREG BRAIL: OK. But we only have 24 minutes,
so let’s not do that. [LAUGHS] PRITHPAL BHOGILL: Yes. All right. So back to you. GREG BRAIL: That’s really cool. Let’s go back to the
slides for a sec. So we showed how
we can do OAuth. Now, in the interest of time, we
did the simplest possible form of OAuth, which is the client
credentials grant type, or informally known
as two-legged OAuth. You’re probably asking,
yeah, but I need to authenticate my end users. And I need to
authenticate the end users using my Active
Directory, or using my own internal
single sign on system. That’s extremely common. In fact, almost every
Apigee customer does that. It takes a little bit
longer to configure, but it’s all the same kind of
process you’re seeing here. And it’s a very common thing
that we do with our customers with OAuth. But I noticed that as
we were doing this, you’re kind of doing everything
in the Apigee console. I really want my developers
to have self-service. I don’t want them to have
to call you up, and have you log into that
thing, and push a button to create an API key. I want to push a
button, and I want to– as a developer– have this thing
work just as well as the Google Cloud APIs do. So can you show us a little
about how we might do that? PRITHPAL BHOGILL: Absolutely. Can we switch to
the demo, please? So you’re right. You need to be able to
advertise to the world with an awesome API. And the way to do that is
through a developer portal. In this new Apigee
experience, we’ve actually enabled that capability
in the hands of developers. So I’m going to click
on this icon here, and we are actually going
to build a live portal as we go along in this demo. Let’s click on the
plus portal icon, and let’s call it the Brand
new Hotels API Portal. And you can see this
is a live URL which is being generated as we speak. Let’s go ahead and create it. So once I do that,
it gives me something very basic and simple. And when I click on this, it
gives you StreetCarts page. Not something which I expected. I’m trying to build
a Hotels API, right? So let’s see how we go about
changing and customizing and show you the power
of how you can do that all from within the tool. In this section, I
can go to the pages. So think about my
role changing slightly where now I become part
of the content team who’s responsible
for doing that. And you can do that from
within the same tool. Apigee Edge has our
back built into it, which means you could
essentially have a role of that of a content developer who has
access to only building out this portal and not mess with
the API proxies and vice versa. So in this case, we
go to the homepage and we can start making
some changes here. We can call it Hotels
and just change it in a couple of places. And I hit publish. So in this case, if I
was to refresh this– great. I see that change, but I don’t
really like the picture here. It seems a little bit odd. It doesn’t look like a hotel. GREG BRAIL: We don’t any
hotels in Chicago anyway. We’re starting in San
Francisco and New York only. PRITHPAL BHOGILL: So
let’s go change that. Well, how can I really do that? I can go back to the
Hotel’s main page out here– the portal page. And I will upload some
handy files in here. So first go and delete
the default logo which has been here. So right from here I’m
going to actually add a couple of files– in this case, the logo file. I’m not a UX developer,
so just for the record– GREG BRAIL: [LAUGHS] You spent
a lot of time on that, I see. That’s awesome. PRITHPAL BHOGILL: And a
background, which I think is really neat. Now let’s go back and go to
the team setting out here. In this, you actually have the
ability to change a few things. You can change– and again, this
is very simple markdown kind of format. I can go change the footer,
the background, everything– GREG BRAIL: Oh, boy. CSS, OK. PRITHPAL BHOGILL:
It’s simple, easy. It’s just built on CSS. I know, some folks
don’t like it, but again, this is very simple. GREG BRAIL: Hey,
it runs the world. PRITHPAL BHOGILL: I
think I got it right. Let’s go ahead and
publish this portal. GREG BRAIL: Hey, look at that. PRITHPAL BHOGILL:
And just like that I have a branded developer
portal within a few clicks and minutes. Right? It didn’t take that long. But there’s something which
I also would like to add in, we have a hotels API. GREG BRAIL: Yes. PRITHPAL BHOGILL:
That’s missing out here. So let’s see if you can add
that to the developer portal. So go back to the
portal page here. You can click on
the API section. In this API section, I’m going
to add the exact same hotels API spec that I had used. So let’s pick the Hotels Gold
product, because your API spec is mapped to the product. We’ll go add this. GREG BRAIL: Yep,
that’s the spec we created in the beginning
of this demo, right? PRITHPAL BHOGILL: Exactly. GREG BRAIL: And the
snapshot is ensuring that if I change it online,
it doesn’t immediately get published until
hit Save and Complete. One thing I want to go check
on is once you go to the spec, let’s make sure the spec is
looking the way it should be. Here’s the hotel spec. Right? Looks good. You go in here and
make sure we’ll get a snapshot of the latest one. Let’s take this and save this. Once I’ve done this, I want
to go to the Hotels main page and maybe add one
more comment to it. Hotels API, excellent. And hit Publish. So I just made a
couple of changes. I added an API snapshot
and updated the definition. So if I go here
and click on this, you can see the
Hotels Gold product. And you can also see
the API spec– oh. Looks like it didn’t load it. I think let’s move
on in rush of time. But if– GREG BRAIL: It’s
supposed to be here. It works. PRITHPAL BHOGILL: With
this you would actually see the API documentation render
out here in a very similar way that it worked as we
had in the spec editor– but from a consumer perspective. GREG BRAIL: Now, can I
actually sign up for a key here and get that API key and
credentials we saw earlier? PRITHPAL BHOGILL: Yes. We haven’t enabled that, but
in real world what you would do is you would take
this to the next step, and the same API key and secret
that I actually generated from the API provider site– you could have a developer
portal through which you can expose that capability
and have them generate the API key in a self-service way. GREG BRAIL: Right. And we’re not going
to go into all of that in the interest
of time, but that’s exactly why this ability
to create a portal– and the customization of
the portal is very simple. The portal is– it’s just a web
app that calls the Management APIs in Edge. Everything we’ve done in the
UI has an associated API. We have a portal here which is
kind of built into the product and very easy for
customers to deploy. But we’ve also had customers
build their own portal in their own way completely
custom with heavy input from their branding teams
on top of our Management API and really everything
in between. So you can get
going very quickly as Prithpal was showing. And for many APIs
that’s all you need, but you also have the ability
to do extensive customization. So let’s go back to the slides. And we’re going to talk
through a few more sections of the lifecycle a
little bit more quickly. But we wanted to get the real
basics of the whole product there. Now, once I’ve done this, I
probably want it to scale. And I have to assume that the
Apigee Edge product running as a service can auto scale. It runs on top of Google Cloud. It even runs on top
of Amazon Cloud. All those capabilities
allow us to take advantage of auto scaling. And some of the
interesting things you can do with Edge as a service– we’ve done a lot of work to make
sure that it not only scales, but it’s very reliable. So for instance,
everything in the product is replicated
across data centers. We use technologies
like Cassandra. Remember, we run in a
lot of different places, not just the Google
Cloud, which allows us to have things
like OAuth tokens, and quotas, and
things like that work even in the failure of an
entire geographical region. And our customers
who run on-premises, they almost always run in
their own data centers. And they almost always have
more than one data center. And none of them has asked us–
actually one person asked us– for the old traditional
failover disaster recovery drill on the weekend thing. What they want is
everything to be active active across their
data centers at all time. Now, this chart here
shows the common case of auto scaling,
which is most APIs– just like most web
apps have a chart that looks kind of like this. You have big traffic
peaks Monday, Wednesday, Thursday,
and Friday, and whatever geography you’re in. You have smaller traffic
peaks on weekends, and it’s pretty predictable. And auto scaling systems, like
the ones built into the Cloud, can easily keep up. Because every 10
or 15 minutes they kind of average
what’s happening, and they add servers
and take them away. And interesting use cases, we
have some customers whose peak does not look like this. So for instance, we have
a customer in the clothing industry that does auctions of
items of clothing periodically. So for instance, at
9:00 AM on Thursday, they’ll auction a new limited
edition item of clothing to their fans who will use
their app to try and get this item of clothing. And their API traffic goes
from one or two requests a second, to 10,000
requests a second in the space of about a second. These kinds of auto
scaling algorithms don’t work there, because
there’s no auto scaling system in the world that can
detect traffic ramping up over a two or
three second period and spin up 50 or
100 server nodes. So we also have the ability
through our global support center to configure what the
parameters of this auto scaling are. And Apigee Edge– we send cell
to a lot of large enterprises, and some of them like the idea
that they can call someone up and say, hey,
we have a big event happening tomorrow morning. Let’s make sure we’re ready. Let’s kind of adjust those auto
scaling parameters in order to make this sort
of thing happen. That’s a real important
thing that we do. Now, if we move on, of
course, none of this would work if we
weren’t monitoring. So I talked about the scaling. I talked about all
those kinds of things, but obviously within our
global support centers we’re monitoring
what’s happening not only with the Cloud– we
run on great Cloud platforms– but with our own application. Our certain API is using an
excessive amount of traffic, and we’ve gotten to
the point now where we have great people
working behind the scenes, as well as a lot of
automated monitoring where we often detect problems
with a customer’s back-end API before they do. And sometimes we
call them and say, hey, we’re noticing a lot
of errors from your API. We’re noticing that the API
traffic is coming to Apigee, but it’s not necessarily
getting to you. And they say, oh, look at that. We’re having a problem. So it’s a very
interesting world that we live in where we’re
kind of sitting in the middle of a
lot of API traffic. But since we’re sitting in the
middle of this API traffic, there’s some interesting stuff
we can do about analyzing it. All the API calls
passing through Apigee we can gather metadata. Because we do things like
OAuth and API key validation, we can record for you which
developers, which applications, which geographical locations
are accessing the API the most, and allow you to do some
interesting things in order to run your API program. Remember, in a lot of cases
you may have an API product management team that is
actually trying to turn this API into a product. And even if it’s not– even
if it’s just for customers, or partners– it’s very important
that you understand, what are the most popular APIs? What kind of SLA am I achieving? Are my APIs very slow? Do they have a high error rate? Are certain applications
more popular than others? Are there giant changes? Has an application suddenly
gotten wildly popular? Which might mean either you
have a hit on your hands, or someone has compromised
some application credentials, and they’re trying to use
the API in a way that’s not supposed to be used. So for all these
reasons, there are a lot of analytical
capabilities in the product. And let’s see if we can take
a look at how those work and what kind of
information you can get. PRITHPAL BHOGILL: Sure. Let’s switch to
the demo, please? So back to the
Apigee Edge UI, you can click on the analyze
tab, and this gives you options around many
out of the box reports that are generated by
default by the platform. So I was talking
about you have an API proxy that’s built
as API traffic is piping through the gateway. We collect a lot of
different kinds of metrics. Many of them we
kind of publish out of the box in terms
of these reports. So the very first one out here
is the API proxy performance report. Now, this gives you
a very broad idea of how the API
proxies are doing. And which means the
general amount API traffic piping through a system. In this case, I have a
few different API proxies which are deployed in this ORG. And you can see the
total traffic coming out through here. In a very quick snapshot–
the kind of number of errors, the percentage of error,
so on and so forth. You can also see
the amount of time which is being spent in the API
proxy versus the average target response time. GREG BRAIL: So
the amount of time that Apigee might
be taking to execute those policies I put in? PRITHPAL BHOGILL: Exactly. GREG BRAIL: Keeping
in mind, policies are sometimes simple
things like Spike Arrest, or sometimes they’re my own
JavaScript code, or my own Java code. And that can be any number
of milliseconds, right? PRITHPAL BHOGILL: Exactly. So this starts to
give you a good idea of the kind of things you
should be doing within the API platform. Certainly, we’ve
run into situations where customers are doing some
heavy weight transformation. There are some other tools
which are really good for that. Your API platform is
the tier of agility. This is your face to
the outside world. You want to keep it as
quickly as possible, process as many
transactions as possible. There are a bunch
of different reports which we’re not going
to go through today. But again, you
can check them out if you have a free trial
account, which anyone out here can sign up for today. But what I am going to
touch on very briefly is the notion of
customer reports. So although a lot of these out
of the box reports are great, but many times you
had the requirement if– think about API has
become your digital channel. Businesses want to know what
kind of orders am I processing. Right? What kind of hotel reservations
have gone through this? So you need the ability
to be able to create custom, which can be
presented to a business user. In this case, I’ll just
give a very simple example of a custom report. In this case, it just shows you
the amount of traffic coming in from different APIs. Now, these APIs could represent
different business segments, such as orders, such as
payments, so on and so forth. And using some
simple heuristics, we aggregate the data. And then you have the ability
to kind of dissect through this and figure out what’s really
going on with the APIs. You can delve deeper. We have a bunch of different
kinds of metrics out here. If you were to click
in the edit tab here, you can just add different
out of the box metrics, which are available at a high level– all that traditional stuff
that you can expect to be. You can also see some
custom dimensions out here. These are the ones which
you as an API developer can have the ability to
create some custom dimensions. So imagine recapture
usually any information that can be gleaned on from
the header information, or any kind of commonly
available user agent stuff that’s available. But as an API developer,
within the API proxy you can actually add policies,
such as a statistics collector policy, and that will
start scraping out all the useful
analytics that you need– in this case, the order
amount and the order discount. Once you do that, you can add
various kinds of dimensions. And you can see the amount of
stuff that’s available to you– some common dimensions which
you can slice and dice using the geographic region
that you’re coming from, any specific developer app
perhaps who’s calling it. You can use some custom
dimensions out here, and many of the
advanced dimensions are available for you
to use by default. Once you do this, you actually
have a very simple report, which can then be
shared in a secure way by different kinds of users. GREG BRAIL: And of course,
the reports have APIs. PRITHPAL BHOGILL: Exactly. GREG BRAIL: So you can
query them from an API. Cool. PRITHPAL BHOGILL: OK. Back to you. GREG BRAIL: So back to
the slides for just one more second. So that’s how the
analytics works. So we’ve got some really
comprehensive capabilities there. And the last thing is, let’s
talk a little bit about money. I want to make some
money on my API. Now, it turns out
there are a lot of ways to make money on your API. Back on our Hotels
API, I might make money by having people
stay in my hotels. Or sometimes I make
money because my API drives other product sales. But I might be doing
something really interesting. I might be in finance, and I’m
trying to do a market data API. Those folks are
actually next door. Or I might be in the
news, and I might charge a lot of money
for extremely, extremely timely news, or who knows what. I might want to actually
charge per API call and have different tiers,
and different kinds of prices for
different API calls. Is there a way that
I could do that? PRITHPAL BHOGILL: Absolutely. Let’s switch to the
demo again, please? This is actually by design,
going from slides to demo, just to make sure you guys are up. GREG BRAIL: The person taking
the screen apart is not by design, but that’s okay. [LAUGHTER] PRITHPAL BHOGILL: So let’s use
a live example in this case. I’m going to very quickly talk
about Pitney Bowes, which was also mentioned in the Keynote. And this happens through
a developer portal. So I give you a very
broad and very high level example of how
you could take and build a developer portal. This is another example of
how they take in the developer portal and customize it. And they also happen
to leverage some of the monetization capabilities
of the Apigee Edge platform. If you think about
monetization, once you hit the level of
maturity in the APIs, and you want to make
money off your APIs– which would seem
natural at some point– you can use some of the
monetization capabilities provided by Apigee Edge. We’re going to review
the consumer side of it, but from the producers side– or the providers side of APIs– you can create
different grid plans. Because you may
want to offer APIs so that people can consume
based on different kinds of dimensions. Perhaps you want to sell APIs
using volume based pricing. Right? Maybe these need a number
of API calls per month, or you may want to
charge separately for each transaction. GREG BRAIL: Or you might want
to do revenue sharing where you give developers
money for building apps that use your API. PRITHPAL BHOGILL: Exactly. So Walgreens is another example
of how they use revenue share when they have
their partners who are sending business to them. So the developers get a cut
of that transaction amount. So in this Pitney
Bowes developer portal, you can see they have
different kinds of APIs. I’m going to click
on the GeoSearch API and click on pricing plans. This gives you the
consumer side of it. So if you are an app
developer trying to use some of the Pitney Bowes API– and this gives GeoSearch–
you can sign up for different kinds of plans. In this case, they
are doing volume based pricing where you
can get 5k, 10k, et cetera, and different credits. In this case, you can
build custom plans. So this gives you one glimpse
of how you can use monetization both from the provider’s
side, and in this case, from the consumer side,
to now monetize you APIs. GREG BRAIL: So what’s a credit? Is that like different points
for different API calls? PRITHPAL BHOGILL: Exactly. So in this case,
they have this notion of some kind of a
freemium tier where when you’re using
a higher tier they give you more and
more credits, so the upside for the developers– GREG BRAIL: Oh, I see. That’s interesting. PRITHPAL BHOGILL: –to
use more and more APIs. Exactly. GREG BRAIL: And
different API calls could have different
weights, essentially. Right? PRITHPAL BHOGILL: Exactly. GREG BRAIL: OK. Cool. PRITHPAL BHOGILL: Awesome. So back to you. GREG BRAIL: OK. So back to the
slides one last time. So what we’ve done
really is we’ve gone through the whole
lifecycle of APIs. We’ve talked about everything
from designing a spec and publishing the
spec as documentation, to creating an API proxy
and adding policies. So I can have some of
the different levels of service around my API without
changing what’s on my back-end. We talked about how to
create a developer portal and actually publish that
API for use by developers. How I can use analytics to find
out how my API is being used. And if I want to
charge for my API– like Pitney Bowes is doing
using the Apigee Edge product– how we can do that as well. So basically that’s what
we do with Apigee Edge. We provide a product
that allows people to configure all of that stuff
to work the way they need it. So thank you all for coming. PRITHPAL BHOGILL:
Thanks for joining. [MUSIC PLAYING]

1 thought on “Manage the full API lifecycle with Apigee Edge API platform (Google Cloud Next ’17)”

  1. The reason publishing of the OpenAPI Spec to the Developer Portal didn't work was because Prithpal associated the spec with "Hotels" instead of "Hotelz" at the 42 minute mark

Leave a Reply

Your email address will not be published. Required fields are marked *