[MUSIC PLAYING] CHRIS LATIMER: Thank
you, everybody, for attending our
session here today. My name is Chris Latimer. I'm one of the product
managers for Google that focuses on APIs
and API management. Before we start the talk today,
I'm curious, have any of you or how many of you
have been in a session where we've done questions
and answers using Dory? OK, so it's new
to a bunch of you. So this is an
internal Google tool that we use all the time for
big sessions like this, where we want to make
sure that not only you have a chance to
ask your questions, but also that from an
audience perspective, you can vote up and
vote down questions. So we can make sure that
we're addressing and answering the things that you feel are
the most important as a group. And of course, we'll have mics
here and over here as well. So when we get to the
Q&A portion of the talk, feel free to step up
to the microphone. And we'll be happy to answer
any questions that you may have. So a little bit of
background on me-- so I joined Google
about two years ago. Before that, I was working
for a company called Apigee. A lot of you may
have heard of Apigee. We're an API
management platform. We got bought by Google. And so for the last
four or so years, I've been spending almost all
my time talking with customers, different companies
about the API programs that they're creating,
the challenges they're running into,
trying to figure out how it is that we can
build a platform that's going to make our customers
the most successful as we can. And before that, I
was interested in APIs because I was building
a lot of APIs. And when I first started
getting into APIs, there was a big debate raging
in industry between things like, should we use SOAP,
or should we use REST? And at the time, it seemed
like SOAP had basically won. Enterprises were viewing APIs
as this novelty technology for the Facebooks and
Twitters of the world and not really something that
serious enterprises would need or be building
to satisfy their use cases. And then, a couple
of things happened. We had things like
big improvements in the way that websites worked. So we went from
pages that needed to reload every time to
single-page apps that are much more responsive. And if you look at
frameworks like Angular and others that have
come out, they natively consumed this JSON. And so all of a sudden,
we had enterprises building APIs to support
these new types of websites. And then of course,
at the same time, mobile just became the
explosion that it became. And as a result, the same
type of thing applied. So if you've ever
tried to consume a SOAP service from, say, like an
iOS app or building an iOS app that uses SOAP, it's a
pretty challenging exercise. It's pretty trivial if
you're using a RESTful API. And so we had a lot
of companies that were starting to build more,
and more, and more APIs. And so it's great
that today, we're sitting here in this completely
filled room talking about APIs, and somewhat
surprising that SOAP-- even though it was
the de-facto winner-- I'm pretty surprised if
we find a SOAP session how to build better SOAP
services on App Engine or how to optimize your
Kubernetes cluster for SOAP. But we've got a lot
of people that are interested in API management. So a lot of you
are probably like, why are you talking about
the history of APIs? What's that have to
do with anything? I came to a best practices talk. So the reason why I like to
start this talk by describing a little historical context
is that the circumstances that happened around web and mobile
led to a bunch of API programs springing up just
out of necessity, without a lot of foresight. And this gives us the
ability to go and look at a lot of common
problems that have happened from these programs, which
really had no management upfront. And so one of the patterns that
I observed as I go and talk to a lot of enterprise customers
who build out a lot of APIs, is that they don't really set
out to build an API program. Usually, what
happens is something more like this, where a project
just happens to come along. Maybe we're going to build
out something in Angular. Somebody says, let's build a
new customer-facing website. Let's build something
for our call center. Great, we're going to do that. And it just so happens that
this application needs an API. We launch it. Everything is going
according to plan-- so far so good-- until a
whole bunch of other projects come along. And each one of those projects
needs to create APIs as well. So we end up with mobile apps. We end up with
self-service kiosk. We end up with all these
things that are needing APIs. And so then, we start to run
into some of the challenges, and we start to see the
need for API management. So if you start looking
across these APIs, you'll see that they're really
not necessarily consistent. You'll see things
like, maybe I've got a preferred approach for
doing things like pagination. Maybe I like to
use limited offset. Maybe you like to use
page size and page number. Maybe somebody else likes to
use a current set of records. Maybe I like to use customer
uppercase I, uppercase D. And you like customer uppercase
i, lowercase d, or camel cases, or all these different
permutations. And so what ends up happening
is that as a developer, as you go to try
to use these APIs, you're having to learn each
one over and over again. We have more
friction than we need to have as we're trying to
build API-driven applications in our organization. The other thing
that happens is, we tend to run into a lot of
the same type of challenges. So if you have 10 different
teams that are building APIs, you may have 10 different
teams that are building out solutions for
things like caching, like traffic management,
quotas, security, and so forth. And so not only are
these APIs inconsistent, but we're spending
a lot more effort than we need to to actually
get them up and running and out the door. And then, probably worst of all
is that because these APIs are hiding in silos within
your organization, they can be hard to find. And so we end up with APIs that
ultimately do their purpose. But we don't get a lot of
the re-usability aspects out of them. We don't get a lot of
the streamline benefits, and people aren't
able to find them. And usually, it's
about this time when companies
recognize we should get more serious
about API management and how we're going
to manage our APIs. And so that's when
they typically start to look at
platforms like Apigee and start to think,
what exactly is it that we should be evaluating? And what capabilities should
we have in an API management platform? So let's talk a
little bit about that. So if currently you don't have
an API management platform, you've got something
homegrown, or you're just evaluating what
sorts of capabilities should we have to be able to
build an effective API program, you'll start to see
things like this. So we want to have
an API catalog. So discovery is important. We want people to be
able to find APIs. We want people to be
able to use those APIs. And we want to start
thinking about things like the different
audiences that we might have for those APIs. So we want to make sure
our platform can do things like support internal
APIs and partner APIs. Maybe when somebody signs in,
we want to know which audience they're in, and we want
to be able to make sure that we can put in place
role-based access control to ensure that only the right
people should have access to those APIs. Depending on the types of
things that you're building, you might want to have
self-service on-boarding. So I know in companies
that I worked for, a lot of times the
hardest part of re-use was just being able
to track down the API and talk to the right team to
actually get access to those. One of the things that API
management can do for you is it can streamline that
entire process. So we can find the APIs. They can give you a
way to get credentials the same way you
would expect to be able to go to Facebook or
Twitter, sign up for their API, and start using it right away. There's no reason
why you shouldn't be able to do that within
your organization as well. And of course, you should
have good documentation. So this can, of
course, be things like if you're using open API
for documenting or specifying your API structure. We want to be able
to pull that in. But you may want to have
additional things as well. You might want to have longer
form documentation that describes, here's how you get a
OAuth token in our API program. Or here's how we expect
you to secure this API. Maybe you want to
put things in place like SDKs or additional files
that people can download. These are all
things that you can start to think about as you
are looking at the capabilities that you want from an API
portal type experience. Another thing you
want to think about is analytics and how you're
going to track things, what you need to track in your API. So of course, you're going to
have things like, you probably want to know if
all of a sudden you see a big uptick in errors
that are coming through or a big drop off or
a spike in traffic, if things start taking
longer than you expected. Those are all
things that you want to be able to put in place. And you probably want to
be able to measure business impact to your APIs as well. So in Apigee, we like to talk
a lot about APIs as a product and taking your APIs
and productizing those, so that you can expose
those to certain audiences. These can be things
that are internal. Maybe you've got products that
represent a line of business, and you want to be able to
offer those capabilities to other lines of business
within your organization. Or you might want to productize
for an external audience. Maybe you've built
things internally, but they've got some
sensitive information that you want to
create something that's more partner-specific. And you don't necessarily
want to go rewrite that API from the ground up. We want to be able to look
at things like productization to help with that
type of problem. And you may even want to
tie that to monetization. So a lot of Apigee's
customers actually have taken their API, the
data they gained over time, and turned those into
monetized products that they offer to the public or
to specific business partners. So that's from a
consumption standpoint, but we still want to
have all the capabilities that we think about typically
with an API gateway. So for example, we want to
have in place access control. Now, you might be looking
at things like OAuth as a standard for API security. But you may need to tie
into existing systems in your organization currently. Maybe you use Ping for
identity access management. Maybe use LDAP, or Active
Directory, other products that are out there. You want to make sure that you
can bridge that gap between API security and the things
that you have to work with in your organization. Likewise, you want
to think about things like transformation
and mediation. So these are capabilities
where perhaps, if we have all those
inconsistent APIs that people have built, and we
don't want to go rewrite them from the ground up, you
can put an API management platform in place. And maybe we can homogenize
some of those query parameters that people have built. We
can offer the same uniform experience to developers without
actually going and rewriting everything from the ground up. You probably want
to start thinking about things like traffic
management and quotas. So I know I did not have a
sufficient appreciation for how complex quotas could be
when I joined Apigee. It actually seemed like
a pretty simple problem. I give you 10 calls, and
I'm going to increment a counter until it gets to 10. And at 11, I'm going to
stop giving you access. What's so hard about that? And then, I was introduced
to extremely high volumes of API traffic. And so if you start
getting things like 5, 10, 15,000 requests per
second, keeping a quota in sync can become a challenge. And then, if that
quota is distributed across multiple geographies,
it becomes a really non-trivial problem. So these are some of the
things you want to think about as you're looking at
these gateway type capabilities in API management. Of course, we have to think
about threat protection. Any time that we go and we
want to expose our data out to the internet
especially, you're going to want to
make sure that you're thinking about
things like, are we protecting against DDoS attacks? Or are we protecting
against people trying to put in
place SQL injection and cross-site scripting,
those type of attacks? So do we have the
capability in our platform to be able to address those? And then, things like
caching and optimization-- so a lot of times,
we built services that maybe have been
around for a long time, back before we had a
lot of mobile use cases where customers expected a
very quick response time. So there are
opportunities for us to build and use
caching in our platform to improve that
overall performance and experience
that we can deliver through API-driven apps. And so as you go through
this type of an exercise-- I'm sure many of you
gone through this type of an exercise-- typically, you end up
making a selection. You decide what platform is
going to work best for you based on your use cases. And it's about that
time that you realize, now you almost have two
problems because you still have all of the API
management concerns that you have from all
the APIs that you've built and all those type of problems. And then, you have
this new platform. You have to figure
out how exactly are we going to configure this to
build a successful API program. And so just like
managing anything else, when we go to manage APIs, we
really have to ask ourselves, what does success look like? And how are we going
to track, and how are we going to measure
success over time to make sure we're on
target to achieve our goals? So in talking with
a lot of customers, I've asked so many
customers, what exactly do you envision when you
think of an API program that's successful? How would you measure that? How would you think about that? And I've heard of a number
of common themes over time. And I've tried to
categorize these. So one of the first questions
that new customers want to ask is, where should we start? We've built a bunch of APIs. Should we just take every API,
every service we've built, dump it out on our dev portal,
let people start using that? And that's one approach. It's usually not the
most successful approach. Where I recommend
that customers start is by looking at the
end user, and what's going to provide value
to those end users. So I'll give you an example. So I worked with
a large retailer. And so one of the first
APIs that they started with, that they really started
to publish and market, was a loyalty program. And so we talked about how
they were measuring the value. How do you know
if you're actually reaching these end users? And so they did a
couple of things. So one is, they started to
look at traffic for the loyalty program. How many people were actually
coming into their store because they had loyalty points
and redeeming those points? They started to look. They got some early
signals by API traffic. So as they rolled this out
to partners and directly to consumers, they
started to see, yup, we're actually getting
a pretty good uptick in terms of people that are
taking advantage of our loyalty program. And it's driving those customers
back to the store more. And they can watch
that usage in real time on a day-to-day basis. The next aspect, once you have
identified that these APIs are going to allow us to provide
value to the end user, is to convince developers
to start using those APIs. Now, for an internal program,
that's not necessarily hard because we've got a
little bit more control over what our internal
developers are building on a day-to-day basis. But as you're looking at
public-facing APIs, or partner APIs where you're
recruiting people, you want to make sure that
you are offering something to those application developers. And that could be in the
form of a better experience, new capabilities in their apps. It could be in the form of a
direct monetization channel. We've got retailers that are
doing things like revenue sharing monetization. So when you sign
up for their API, you can actually
drive monetization to be your application. And then, when we look at
how customers are actually measuring this, one
of the most common is actually looking at the
number of consuming apps. So if we've been able to reach
the audience that we're after, we get people to be
aware of those APIs. So they're actually starting
to use those and build those. Have we built an API
that's usable by developers and offers sufficient value? We'll also see the number
of developers that are using those APIs go up substantially. And we can also watch and see
how our community is growing. Do we see more questions
either directly on our portal? Are we using things
like Stack Overflow? We see more interests
that are climbing up. And we can measure these, and
we can take appropriate steps to continue to encourage
that type of growth. The third thing is that the
APIs, as they're being used, they generate some type of
ROI for your organization. And this could be in a
number of different forms. This could be from
enabling more partners to on-board on to your API,
growing your partner channels and the number of people
who can sell your products or use your data. It can be in the
form, especially for internal programs, of just
greater internal efficiency. And there's a lot of
time that's wasted by people trying to figure
out does a certain API exist? What team do I need to talk
to get access to an API once I determine
that it does exist? Is there a way that we can drive
efficiency from that aspect? Also, from the aspect of as
people are building those APIs, how can we make our
applications get built faster? And then, we can
also, of course, sometimes just take the APIs
directly and monetize those. So we've got
customers out there, like a large weather
site, they'll offer you subscription bases for
getting access to their weather data, for example. Others that have market
data or accessing things like credit card processing. So there are ways that we
can also look at these APIs as a direct new channel of
business for our organizations. So when we look
across the end-to-end, going from that end user
that's using the application, making sure that we're driving
the ability for the developers to get those apps up and running
more quickly to use those APIs and to ensure that we're
driving the overall ROI, we can think of this as
happening in two parts. So the first part
is API exposure. So what can we do to make
the ability for API teams to create APIs very
quickly, more efficiently to be able to drive the
proliferation of APIs within your organization? And then, we can think
about API consumption. So what are we doing once
those APIs are up and running to actually make it easier for
people to get access to APIs and start building those
things, so we can actually deliver the real tangible
value to our end users. And so again, one
of the things that-- some of the research we
did leading into this talk was to go and ask customers. What are the actual KPIs that
you found that you're tracking? How do you measure the
value of your API program? And so when it comes
to the exposure side-- taking all the data and
things that you've built and getting an API
out more quickly-- we've heard two things. So the first is speed to API. So we we've recognized
the need for something, and we want to get it up
and running, and available, and into the hands of developers
as quickly as possible. And we don't necessarily
want to do that just by throwing more
people at the problem. And so we also want to make sure
that the overall cost in order to get that API out the door
is as small as possible. And the key behind this
is, where an API management platform can help, is that we
can eliminate a lot of the work that you would have
to do otherwise. So how can we use
an API platform to allow us to focus in just on
the things that we care about? We don't necessarily want to
be experts of API management. We want to be
experts of our APIs and building the
underlying business logic. And so we can use an
API management platform for things like security. So using API management,
can we eliminate the need for individual security
reviews every time an API gets published? Can we do things like
embed all those standards that we have, our standard
controls and policies, so that anytime an API call comes in,
we're going to automatically apply the right policies? Can we use it to tie into our
existing IDPs and our existing capability, so that we
don't have to reinvent the wheel every time? Things like traffic management--
so we start to think about some of the threats that can
happen, even with data that's not necessarily sensitive. We have to be aware that
even non-sensitive data can be important. So for example, we may
have like retailers that have store hours, not a
sensitive bit of information, but it's something that's
critical for customers that want to go and look and
see if the store is open. So we don't necessarily want
to open that up to the public, have a huge wave of traffic flow
in, and take that capability down. We can use traffic management
and the API management platform to be able to solve
those type of use cases and protect against
those type of threats. Again, caching will
come into play. So can we do things like-- not just response caching
at the edge-- but can we also do things
like partial caching? Maybe you look at how
your APIs are structured, and you see that it would
actually work better instead of what you
have today if you aggregate two or three APIs. Maybe you see from
analytics there are patterns that are
happening over and over again. You want to optimize those APIs. But you're scared about
handing back stale data. So what we might want to do
is you might want to say, well, we're going
to create a mash-up. We're going to grab two
or three different APIs and put those payloads together. Two of those things
are cashable. We can use partial
caching, and one's not. And we can still improve
the overall response time and performance of that API. And then likewise, we get to
things like transformation and mediation. So if you have an API that was
built for maybe a client server app or something that's
running internally to your organization,
and you want that to be useful
for a mobile app, you can do things like
mobile optimization. We can cut the
payload down, trim out the parts that aren't
needed by the mobile app. Same thing for like
data scrubbing-- so if you've got
an existing API, it's got sensitive
customer information on it, and you want to expose
that to a partner, instead of building another
version of that API, you can use the mediation and
transformation capabilities, scrub that out so that your
same API becomes applicable and usable by more people. And then of course,
we want to be able to track and get real-time
visibility into our APIs. If all of a sudden, we see
that things are going bad-- either errors are coming up, or
the response time is starting to really trail off-- we want to be able to
get visibility into that so that we can take
the appropriate action. From an API
consumption standpoint, some of the things that we
heard when we asked customers were time to Hello World. So we build an API portal. We've let people become aware
of our APIs that we've built. They can get access to those. How long does it actually
take for them to start building something with it? Even just a simple Hello World. So how long before
we see they go from a registered user
to somebody that actually has an app sending traffic in? So we want to be able to monitor
and track that data over time and then improve our
documentation and our outreach so that we can improve those. We can also look at things
like number of developers. So if we're trying
to drive consumption, the consumption
comes from developers that are actually
building apps that are going to be using these APIs. So we want to be able to
see, are we actually getting the adoption that we want? Are we reaching the audience
of developers that we're after? And then, are they
actually building apps? Do we see an uptick
in terms of the number of apps that are being built
as we launch more APIs? And so how do we do that? How can API management
help with that? Well, API management
programs should be building a very
compelling developer experience for your developers. You want them to
not only see here's the documentation, the
APIs that are available, but also see what types
of things are possible. We've got a lot of customers
that are building things like application showcases. So it's very easy for you to go
and say, oh, here's a neat app that somebody built.
Hopefully, that triggers ideas from other developers so that
they can go build their ideas with the portal. And you want to make
it very easy for people to not just see what APIs exist,
but actually try those out as well. So they can start
using those, and they can start experimenting with the
APIs and seeing how they work. As opposed to
writing a little test harness or things like
that, we can actually do that right within the
browser with interactive docs. You can take an open
API spec, load it in, create interactive
documentation, and start using that
really right away. And if we are able to
do this successfully, we've seen some major,
major improvements from our customers. So here's a good
example from Walgreens. So they've been a customer
for a really long time. So what they started
out with, they actually started out with an API
called the Quick Prints API. So somebody at
Walgreens recognized that we have all of
these photo printers that are sitting in our stores. And everybody, some
of you right now, are taking photos
with your phones. And a lot of times, they
just stay on the phone. People aren't printing
them off anymore. So what could
Walgreens do in order to make it easy for people
to take those photos, send them into the store? And their answer
to that question was, we'll build a
Quick Prints API. So we'll build an API. We'll put it on our mobile app. It will let people take those
pictures, send it to the store. Hopefully, we'll get a
little trickle of revenue that comes in and justifies
the space in our store. And what they found
is, they didn't get a little trickle of revenue. They got a tremendous boost
in terms of those users. So the users that were actually
interacting with Walgreens on their mobile channel, on
their store channel, the brick and mortar, and online
were spending about 6x what anybody else
was, the folks that would just come into the store. Because these customers
were coming in to pick up their photo, and
then they were buying shampoo. They were buying toothpaste. They were buying whatever else
that they needed at Walgreens. And it ended up being a
real eye opener for them. Once they realized that, they
said we should open this up. We should take this API, and
we should have let anybody use our Quick Prints API. And so they started
to offer this to lots of other
mobile apps that are out there that allow
you to take photos and print photos off. And so now, they're
up to about 300 partners that are building APIs
on top of this Quick Prints. And that's 300 partners that
are constantly sending people into the stores to come in,
to pick up those photos, and buy other
things at Walgreens. And it just made a
tremendous impact. And so when I think of this
successful API program, I view Walgreens as
really the archetype that I feel like
a lot of companies should strive for because it's
not just necessarily an IT problem. It's really something
that can deliver tremendous overall
business value. [MUSIC PLAYING]
