Using Apigee Edge to create and publish APIs that developers love (Google Cloud Next ’17)
Articles Blog

Using Apigee Edge to create and publish APIs that developers love (Google Cloud Next ’17)

[MUSIC PLAYING] GREG BRAIL: OK. Good afternoon. Thank you all for coming. It’s good to see people. It’s getting late in the day. So it’s nice to have you here. So my name’s Greg Brail. I’m a software
engineer at Google. I’m part of the Apigee team. That’s how I came to
Google back in November. And I’ve been
working for as long as anyone can remember on APIs. So what I’m going
to do today is I’m going to talk a
little about some of the aspects of
APIs that makes developers want to use them. And then my
colleague Prithpal is going to actually
show how to do that via live demo of Apigee Edge. And then Adam
Brancato from Citrix is going to talk a little bit
about his experiences with APIs and some of the things
that they’ve done as well. So we’re hoping that by
the time we get to the end, we’ll get an idea of what it
looks like to actually create an API that a developer
will want to consume, and be able to consume. And then, furthermore,
we’ll get some idea about how you can actually
do that using products that you can use today. If anybody is
interested in wants to learn even more about
Apigee Edge, we’re actually– Prithpal and I are doing
another session at 5:20 p.m. In the basement of the Marriott. It sounds very exciting
to go there at that time. And we’ll be going into
a much more detailed demo of all the aspects
of Apigee Edge, including security, and
transformations, and rate limits, and stuff like that. So let me start out just
for a few minutes to talk a little bit about APIs,
and why they’re important, and why we use them. How many of you
work for companies or are in a position today
where you’re offering APIs to customers, or third
parties, or even internally? OK. That’s a pretty good crew. That’s awesome. So this may be
preaching to the choir. I imagine if I asked you, how
many of you are using API, it’s probably all of you. And you probably have
opinions on what kind of APIs you like to use. But let’s make sure that we
make a little bit of time to understand why APIs. I don’t spend a ton of time
on this high level stuff, but I wanted to set
a little context. Obviously, today’s world
of digital business is built on APIs. And APIs are used in a
lot of different contexts. You know, here we
have an example of how one company could offer APIs
that are used by customers, by partners, by employees, to
host all kinds of back ends for all kinds of things. And it’s not really a
surprise to us today that APIs are being
used in a way that enables all kinds of
interesting businesses. When we often talk
about API with Apigee, we almost always
start with this slide that we call the
digital value chain. And it kind of shows all of
the components of the API lifecycle, all the way
from on the left where we have actual end users,
real people who use web apps, and native apps,
and various devices that consume digital services. All the way on the
right we have the back ends that actually
hosts those APIs. Those back ends could
be brand new systems. Maybe you built something on
App Engine, or built it in Node, and put it on Heroku
or who knows what. They could also
be legacy systems as we saw in the
keynote this morning where they were
taking a SOAP system and turning it into an API. And the stuff in
the middle is what really connects everything
together and makes the API real. And there are really
two aspects to it. And I’m going to talk especially
about the first aspect, which is connecting
the developer– the person who builds the
app that uses the API– with the API team. That’s you, folks, who
raised your hand earlier, the people who are
offering the API. And that’s really about how does
a developer learn about the API and understand the API and
get access to that API, and what are some of the best
practices that make an API something a
developer will really be excited about using,
rather than using it because their boss
told them they had to. At the same time there’s
a technical component, how does the app actually
connects to the API? How do we put in the
right layers of security, and traffic management, caching,
and all the kinds of things that we need in order
to take something that may be a back end system
that might be brand new, or might be a legacy system
that wasn’t designed to handle the volume or the
complexity of the internet, and of these connected devices? And for that we have platforms
like the Apigee API platform. And again, our demo today
will be focusing mainly on the developer
consumption side, but we’ll touch on some
of those aspects as well. This digital value
chain actually can go in either direction. You can start with sort of a
SOA enterprise software world where you start with services
that you want to expose, and think about exposing them. But often it makes a lot more
sense to start on the left. Think about what you want
to offer to your customers. And then, by
definition, what you want to offer to developers? What do you think
they want to use, and you can build your business. And it turns out you may have
seen the slide this morning and also Ed Anuff did a great
presentation yesterday on this. There are actually a couple of
different types of APIs, right? On the bottom we have
APIs that are services. These are the kind of APIs
that if we’re an enterprise computing today, if we ever
had anything to do with SOA, even if we’re talking
about micro services, these are the kinds of APIs
that as developers, we’re pretty comfortable with. It’s an API that offers you a
way to connect to some back end service. And that’s when we
think about things like onboarding and governance. There are also on the left,
however, APIs get used a lot, and get used a lot
by Apigee customers, to enable interactions. So APIs that enable
interactions are more about enabling mobile apps. And that’s where
we get to a case where there may be one API
for all the apps in the world, or there may actually
be lots of APIs that are customized for
different platforms. This is something that
companies like Netflix are known for doing extremely– at extremely large scale,
where literally there is a different APIs for
every type of device because we want that device
to have the best possible user experience. And this is also where some
new technologies like GraphQL will come in that let a device
customized their responses it needs for the best performance. And then, finally,
we have something that’s starting to be a
new thing for businesses that aren’t in the
technology business, which are APIs as products. Google’s been
offering AP products for a long time– the Maps
API is very old right. We have– and all the things
that are part of Google Cloud are APIs that are
offered as products. But now we’re seeing
more and more companies be able to offer where basically
the API is the product. And the way that
they make money is by monetizing
consumption of the API. And these APIs fit
into ecosystems. And an important
thing to remember, I’m going to talk a lot about
the API developer experience as if it’s coming
from that outer ring, the public ecosystems. These are the APIs that
as developers you all know and understand. The Google Cloud APIs,
the Twitter APIs, the Facebook APIs. And when people talk about
APIs with Apigee, they often– especially a couple
of years ago– would start with
the assumption that having an API means I
have to offer an API to any developer in the world. But actually, the vast
majority of these APIs are more on the internal
part of this ring. They’re used internally,
either within an enterprise, or they’re used by a company
to support applications such as mobile applications
and web applications that the company builds. And we’re seeing an
increasing amount– and where the API economy
really gets interesting is in the middle with these
partnering APIs, in industry standard APIs. So where customers are now– when they used to, for
instance, in financial services communicate with trading
partners, and business partners, and partners,
and other businesses using a proprietary format like, Fix,
Swift, or FTPing files around, or mailing tapes to each other,
increasingly those interactions are happening via API. And that’s something we’re
going to talk about as well. So most APIs turns out
are actually internal. A minority of the
APIs and a minority of the API traffic in the
world are these public facing external APIs that
have the beautiful developer portals. So who cares if
developers love them? So let me do a little
bit of evangelism so you can at least go back
and tell your friends why it’s important that we pay attention
to how the API presents itself to the developer. First of all, developers
hate to waste time. That doesn’t mean
developers are lazy. But it means developers
want to do things quick. So if a developer can pull up
curl, and test out your API, or if a developer
can call your API from a Node.js application
or an Android app or an iPhone app with just
a few simple commands, they are going to be happy. If the developer’s got to
learn a complex proprietary SDK and some weird security protocol
and wait for legal approval, they’re not going to be happy. And if they have a choice of
APIs, they might move away. Same thing happens especially
for both internal and external developers. But if you think
about partners, when you are offering an API
to your business partners, or to your customers as
a business in a business to business context, the
thing that we sometimes hear and always makes me kind of
frustrated is when people say, yeah, it doesn’t really
matter what our API looks like because our customers
have no choice but to work with it because we’re huge
company X or huge company Y. And the truth is that,
yes, you can get away with a certain amount of that. But unless you can really
make those APIs something developers will be
happy to use, you’ve added a layer of friction
to every interaction. Every sale, every–
everything you do becomes that much harder
if the developers are only using the API because
they have no other choice. Successful companies that run
API businesses like Twilio, for instance, one of
the reasons they succeed is because developers
love to use their APIs. And they say why do I
have to go through all this complicated stuff to use
the thing you made me use? Why don’t we just use x? So let’s talk about some of
the aspects of great APIs. And this is kind of my
list of seven things. And I’m going to basically
go through each one of them. But things like self-service
and sign-up and documentation are tremendously
important to API adoption. And if you look at the
APIs that are very popular and used widely in
the world, you’ll see that each one of these
does these in a very good way. And this is why
we’re going to talk for a few minutes about
what those things look like. And then Prithpal is going to
come and show you how to do it. So we’ll start
with self-service. I think self-service is one
of the most important aspects of APIs for developers. Obviously, if you want to offer
an external API to thousands and thousands of developers
like Google does, you have no choice but
to have self-service. But increasingly,
as API has become what are used for business
to business communications, and are used inside
a large organization, self-service becomes
equally important. So many companies we
talk to are in a world where yeah, we have
APIs, but to use them you have to know
the guy to call, and you have to
go to the meeting, and you have to send an email. And then they type
you into a database, and it takes three weeks. You know, this is slowing
down your business. This is either slowing down
your developers internally, or this is slowing
down those partners and those customers who could
be happily using those APIs. So I have some examples here. Walgreens for instance,
these are customers of Apigee who have produced APIs. They have great self-service
developer portals where someone can come
in and they can actually see what API is available. They can click a button. And ideally, in a
few minutes they can get the security
credentials they need to start using that API. Now, maybe those
credentials don’t let them do whatever they want. Maybe initially
there is a sandbox, or there’s a low rate limit. But you can get started
quickly and learn the APIs. But very closely
related to self-service is how you sign up for the API. So for instance, I
was on this stage yesterday with Ismail
from Ticketmaster. They have a great
developer program. 10% of Ticketmaster’s API
traffic and ticket sales are now coming from third
party apps, apps that were not built by Ticketmaster. And one of the
reasons– and they achieved this in a
pretty short time. And the reason they
were able to do that– in part, of course,
this is my biased view– is because their API is
really simple for a developer to get started with. They have a great portal at You sign up. And if you look at
the sign-up forum, there’s not a whole
ton of information you have to give them. On the right, I pasted a
sign on form from Twitter. Similarly, yeah, there’s a bunch
of legal stuff at the bottom. And obviously, as a developer,
you need to understand that. But they’re not asking for
your social security number or anything like that. In the old days, we used to see
companies who would say, yeah, to use our APIs you got
to fill out this form and fax it back
to our legal team. And it takes two
weeks to review. That’s death for APIs, right? You want developers to be
able to at least get started with those APIs as quickly
as possible via self-service, and ideally manage the whole
thing through self-service, even if approval is needed later
on for higher tiers of APIs access, or to get access
to production data. Documentation is also
tremendously important. The rise of formats like open
API, formerly known as Swagger, really helps with
this because you can specify your API in
a formal way using YAML, and there are a
lot of great tools out there, including one
in the Apigee Edge platform that will make it easy for
someone to visualize that API and learn that API quickly. So for instance, here we
have Payeezy, you know, also the Nest API– you know, these are just
some examples of APIs that have really nice,
clear online documentation. And it’s not just having good
documentation that’s there. Well, OK, I’m going
to talk about it. I thought I was going to
get to the next slide. I’ll come back to that. But documentation is important. But automatic
testing is important. But I’ll take a detour as a
sec, and talk about not only how the API is documented,
but how it’s designed. We can do a whole hour
long session on API design, and have a lot of fun. And we’ve done it before
and perhaps we should. The truth is that there are
a couple of different strands of thought, and there are
different opinions out there. And people have very
passionate arguments. But the thing that
I’ve noticed is always clear is that every
developer I’ve worked with understands what
they don’t like. So this slide actually
comes from an old chestnut of an Apigee presentation from
Brian Malloy about hey, here’s kind of like, the
bad way to do it. And this is how we might
do it if we were just programming in a programming
language, or even using SOAP, right? You start out with get
dog and get location, but before long, you’ve got get
recurring dog walk schedule, and replace sitting
dogs with running dogs. And you’ve made an API
that requires developers– they can’t make
a single API call without going through every
line of your documentation very carefully and
understanding how to do it. And furthermore, your API
is unlike every other API in the world, so they have to
go a whole bunch of research just to make a single
API call, right? At the same time, there are a
lot of API design mechanisms that developers do understand. If I go in front of
a developer and say, we have an API that is what is
usually referred to as REST– and I’m not going to
spend a lot of time on what different people
think the words REST mean– but if I say that my API
consists of a bunch of URIs and a bunch of verbs, and
that to create something you post to a URI,
and to get information about it you do get on that
same API, and to delete it– sorry, URI– and
to delete it you do a delete on that
same API, pretty much every developer will understand
what I’m talking about. Furthermore, if I
say, OK, then there’s a whole hierarchy of you URIs. And they’re documented
in this document, like the one we saw
a little while back, almost every developer
will know how to use it. And if I say, and by
the way, the thing that you send back and
fast to my APIs is JSON, every developer will know how
to use that and every platform in the world, except for
some reason, Java, has JSON built in. So they all know
how to work with it. So these are the kinds
of things that work. On the other hand, there are
some new things coming along that are sort of additional
quivers in your– arrows in your quiver. For instance, RPC,
represented by Google’s gRPC, is a very interesting
tool to use for APIs that are very
performance critical, where you have a pretty good idea of
what the shape of the API is. And it’s not going
to change very often. Similarly graphQL,
sort of a way that uses that same you URI and
JSON and verb mechanism, but it allows a client to
specify exactly what it wants from the API, potentially
combining many API call responses into one. And then, finally,
there’s Hypermedia, which, when used carefully,
can make it much easier for a developer to consume
an API because every API response has some URLs in it. And all the
developer’s got to do is follow that URL to get more
information about that resource and understand what can be done. And like I said, there’s
a ton of stuff out there. But the basics are if you do
what other people are doing and follow the patterns
that developers understand, then there’s very
little friction. I did a whole presentation
yesterday on security. And we’re going to keep the
security part real short here. But basically, just
like API design, there are security
techniques and standards that everyone understands. APIs that need to
authenticate end users, meaning like, I need
access to my bank account, OAuth has become the
de facto standard. OAuth provides a number
of ways that an API client can exchange some security
credentials for a token. And that token is now authorized
to do only certain actions on behalf of one
and only one user, on one and only one device. Furthermore, it
expires all the time. So you have to keep
refreshing it, right? It’s become the
de facto standard. And there are a lot
of ways to use it. Similarly, for APIs that
don’t require an end user to be authenticated,
such as store location APIs, for instance, having
a very simple mechanism like an API key that allows you
to at least understand which application is
making an API call, even though the end user doesn’t
have to be authenticated, is also a very important part
of effective API management. These are things
everyone understands. Making up your own thing. You know, hey, I have a
new security mechanism. I have a proprietary
token format. Download this
little bit of Java, and put it in your client, and
we won’t tell you what it does, but we promise it’s OK. Those things make it harder
for people to adopt your API. And then, finally, I’ll talk
about a few other things. And now we’ve done
the basics, right? We’ve got a well-designed API. We’ve got the right
security mechanism. We’ve got self-service
onboarding. We’ve got great documentation. You can stop there, and you’ve
got an API that developers will find it very easy to work with. But most APIs that are
very widely adopted these days also come
with a set of STKs. So for instance, I
pasted a screenshot from the Google Cloud
APIs where for– the Google Cloud has a big SDK
for many of the cloud APIs. And as you can
see, they have SDKs in all the major
languages, not only that. Right there, they
link you not only to basically how
to get the binaries for your various platforms,
but also here’s the link to the GitHub repo. So if you have an
issue with the SDK, you can understand what it does. You can compile it yourself
if you don’t trust it– by the way, at Google
we don’t trust anything, so we compile
everything ourselves. You can understand the license. And you can submit
pull requests to it if it doesn’t do
something that you need or you don’t like the
way it was structured. Furthermore, if you
designed your API the way I just talked about, the
SDK is not a requirement. A real anti-pattern
in the world is having an API that
only works with the SDK because the data
format is proprietary. It’s really weird to use. It uses some weird binary
protocol, like a database, right? You can’t use Oracle
without the Oracle client. And who knows what that
thing is doing, right? But if you’re working with an
open API that’s well-designed, a developer doesn’t
have to use the SDK. But if you provide them with
SDKs for various platforms, you make them open source, is
a lot easier for developers to feel good about your
code if it’s open source, especially if they’re
going to put it in their proprietary native app. Now you’ve made things
easier for developers. You’ve have made them happy. And they’re more productive. And sort of a little bit more
you know state of the art is more and more APIs now are
able to offer live testing. They’re actually able
to not only combine that API documentation,
but with the ability from within your web browser
to actually test API calls and learn how they work. You can try out
different parameters. You can see with
the JSON looks like. You can figure out
how to parse it. The more complex an
API gets, the more cool it is to be able to
actually test that API. So for instance, Pay
Easy on the right has a whole mechanism for that. I was looking at Ticketmaster. They have it as well, right? Really simple APIs. This curl is fine. But it’s really nice for a
developer to say, oh, here are the docs for your API. You can have a button right
there that says, try it. And now you’ve made life a lot
easier for your developers. So with that said,
I’m now going to go on to how you do this
yourself, and Prithpal from the Apigee team is
going to come up and give you guys a demo. PRITHPAL BHOGILL: Thanks, Greg. Can we switch the demo, please? Awesome. All right. So somehow I’m
confined to this desk today so that I can
talk on the microphone and you guys can hear me. But I’ll try my best
to kind of hand-wave because I usually like to
move around quite a bit. Just a quick show of hands
out here, how many of you folks in attendance have
actually worked with, or used, or seen a developer
portal before? OK. Quite a few. Thanks, Greg. So as Greg touched on some
very important things upfront, the adoption of our APIs is one
of the most important things, right? Who cares if we have good APIs
and, if they’re not adopted, you really don’t make
too much out of it. So in this session,
in this segment, I’m going to focus on what
really makes for an awesome API developer experience,
primarily for the app developer audience who is tasked
with building apps, right? So in this case, I’m going to
leverage the backdrop of Fazio, who’s an online shoe retailer. I’ll use this as an example. And in my role, pretend
I’m a partner developer. So Fazio happens to be
selling shoes online. And they have a very
broad channel ecosystem. So you have a lot of
different partners who can essentially
leverage the Fazio APIs, and build their own apps
to sell Fazio products. OK? So just as in your
own experience today, if you’re using a mobile app,
and if you spent more than four to six seconds on the very
first page of a mobile app, chances are you’re
going to the App Store to look for another app. Something very similar is
happening in the API arena. As Greg mentioned, if
they have a choice– and many of them do– an app developer is going
to go to another API very quickly if they can
understand what the API does. So let’s examine the journey
of me, the partner developer, trying to see how
I can build an app. So I come to the Fazio
developer portal here. I can see some simple graphics
around what Fazio does. More importantly, I can
see three high level classifications–
product APIs location APIs, fulfillment APIs. You can see that
I’m not signed in. So my experience is a
little bit different. I do have access to
some things known as forum, which will
give me some more insight into what people are
generally doing with the APIs. So think about the experience
of me trying to register. And I want access to some
of the API documentation so I can build an app, and
incorporate some of the order API within my ecosystem. So it’s a very simple
registration process. I can just go,
enter my first name, give it a user name, email,
answer a basic math question, and then create an account. In this case, I actually
already have an account. So I’m going to
sign in out here. And they happen to have
different kinds of rules which are supported out here. So assuming the demo
gods are with us, and that I can answer the
basic math question correctly. They should let me in. Great. So I just logged
in as a developer. I created an account. I logged in. And you can see my
choices open up. I have access to
the API catalog. One of the simplest
things that I want to do as an
app developer is for me to be able to browse
the API documentation and get to the orders API. When I come into the
API catalog section, you can see that I can see
a bunch of different APIs out here, around
customer authentication. Let’s just unselect all of
them, and just click on orders. One of the things that
Greg had also mentioned was API as products. This is another example
of how Fazio is now trying to offer their
APIs as products which can be consumed
by their channels, by the partner ecosystem. So let’s take a look at
the Fazio orders gold tier. And this just uses a
different mechanism where you can subscribe to
more number of API calls if you were to pick a silver
option or a regular option. So great. The next what I do is I
want to try and create an app by which I can place
an order on the Fazio API. So then I come to
the orders API page. You can see that
they’ve done a fantastic job of clearly documenting
how to create an order, get an order, cancel
order, so on and so forth. Becomes very simple for me
to imagine how to use this. So let’s go click
on the Create Order. And again, this is
not a developer portal where you have a link
to an API documentation which you can go, download,
and use some testing tool. This all first in
line testing for me. So as the app developer, I have
signed into the Fazio developer portal, and I’ll do a
live API testing here without presenting
any other tool. So in the create
order, I can see that I have a good
amount of help if I need to to explain what
each and every field does. More importantly,
they’re already put in a very
simple test payload. OK. You can see that this
API is protected. I already set the
OAuth credentials. If not, you can click
on this button, sign in, and it will already attach
an OAuth token for you. OK. So it’s a very simple
submit order request. And if I go down here, and
click on a send desk request, it’s sent this order
in, and I got a 200 OK. Right? A couple of clicks. I went into the API
catalog, was able to look at the create order API. I know the payload. I click that. I’m good. So that’s one aspect of
my app experience, right? It looks like a
pretty simple API. So great. How do I get started? Greg also mentioned
about how do you really eliminate the friction? Do you really want to be able
to have this developer send in a request so they can get
their own API keys to access the API, or a fax
machine and wait to get an approval to weeks back? That’s certainly going to
just throw the developer away. Looks like the developer portal
provides a much more simpler mechanism to do that. So they have the My
Apps section here. I’m going to click on this. And as you can
see, this developer has already done some
stuff in the past I’m going to just say I want
to register a brand new app. So let’s call this thing
My First Shoe Ordering App. And I’m going to pick
this orders product. An API product is
nothing but a mechanism. It’s a grouping of
certain APIs which are available at a
specific price point, or at a specific volume metric. So let’s go and do this,
and click Create app. So using this as
an app developer, I’ve just asked for
access to the orders API. And you can see that out here,
I can see the status as pending, right? So as a developer, I’m just
waiting to get access to this. I’ve initiated a request. Now let’s hop over
to the provider side. This is the approval’s
side of the house. This is the product
manager who’d be sitting on the side trying to
approve any app requests which come in. So let’s take a
quick peek at that. So in this case, I’m logged
into the Apigee Edge user interface, which is a portal
that the providers are going to be using. So in this case, I go
on the publish icon, click on the apps
link, and let’s just type in the word shoe. Fair enough, I can see
the My First Shoe Ordering App, which has been
requested to be created, and given permission to
by this new app developer. Within the app
details section, you can see sure that it’s
in a pending status. So I’m going to click on Edit. And I’m going to approve
this app right here. Let’s go ahead and save this. Just in couple of clicks I’ve
been able to approve the app. And if I’m an app
developer, I can now see that this app is approved. So what happened
when we did that? Well, let’s take a look. As part of the app
approval process, I actually now have my own
set of consumer key in secret that I can actually use
to securely call this API. This is very important. There was no human involved,
but from a provider perspective, you can automate that
kind of approval. There could be
certain other APIs they do make provision for which
it gets auto approved, right? So that’s very typical
of many customers who may do that for
some low risk APIs, or where they do not need
any kind of oversight. And then, I as the developer
can go and take a look at different pieces of the apps. Then I start to work with
some of the app calls that I make over time. It would also surface
some of the analytics that are useful for me
as an app developer, not from the
enterprise, but to get a sense of how much did
this app kind of bring up. OK. So let’s do something
real quick out here. I’m going to show the
providers out of the house, and talk about one simple
aspect of how does this app– how does the API
provider essentially ensure that this app
is not abusing the API. OK. So in this case, I could
go on the Create Order, and pretend this app
for some reason was not designed with the right intent. And you can see that I can
continue to just pound on it a few times. And I can still submit
a request, right? On the API provider’s side,
there’s some very quick checks and balances that you can take. In this case, I
need to make sure that this API is protected. So let’s take a look at
this underlying API proxy. An API proxy is
nothing but a facade. That is the thing
which actually sits in between the consumer
of the app or the API and the actual API itself. And that’s where all
the magic happens. You have a lot of
different policy that you can draw up in out
there to enable production. So in this case, I’m going
to do something very simple. I’m going to attach a
spike arrest policy. A spike arrest policy
something very simple. All it does is once
you create that– you can see me adding
a live policy out here. And this policy I can
configure the rate at which I want to limit all the API calls
coming into the API proxy. And the idea is I want
to protect my back end API from crashing and
burning if any app goes rogue for some odd reason. So I’ve added a very
simple spike arrest policy, which in this case happens
to be three requests to that API per minute. So let’s see the effect
of what happens out here. So if I’m within my limits,
is going to work just fine. But if the app starts to
grow a little bit more crazy, you can see that it truly
is spike arrest violation right about here. So hopefully, that
gave you a good taste of what the app
developer experience is. We looked at how things
can be provisioned in a way so you cut all the friction
with app developers. They can adopt your APIs. You also have some tools
on the provider’s side to be able to protect their
APIs from intentional or unintentional kind of attempts. And I would like
to now welcome– if you can go back to
the slides, please– I would like to
welcome on the stage Adam Brancato from Citrix. ADAM BRANCATO: Good
afternoon, everyone. My name is Adam Brancato. I am the manager of customer
applications at Citrix. So basically what that
means is my department is in charge of all the
applications and services that deal with customer
accounts, contact information, single sign on, et cetera. So real quick let
me explain to you guys who Citrix is for
anyone who doesn’t know. Our products and services, they
focus on unifying apps and data in secure digital
work spaces that enable users to work remotely
from anywhere on any device. We have a couple products
that support this. We have our XenApp and
XenDesktop products, which are application and
desktop virtualization products. We also have
ShareFile, for example, which is our enterprise
file storage, file sharing, et cetera. Actually we just
recently released a beta that actually
integrates with G Suite. Then we have a couple appliance
products such as NetScaler. It’s load balancing, firewall
products, et cetera, as well as internet of things products. So I’m going to
talk to you today about the Citrix
API journey, where we began, where we are now,
how we got started with Apigee. So as Greg talked
about, a lot of times you have these
internal services that are not very easy to expose. Or whenever people want
to use the services, they have to jump
through a lot of hoops. And that’s kind of how
it started at Citrix. So we had several
other departments. There’s a lot of
different IT departments and IT groups in our company. We have like, 9,000 employees. So I’m sure anyone in
medium to large company knows what it’s like
with multiple IT groups. Well, our group is the keeper
of the data for accounts, contact, single sign on, all
those items that I mentioned earlier. So a lot of them
wanted access to this. Well, a lot of our
systems are written in legacy SOAP services. For example, we have
live WCF .NET services. And so many new
applications are front end, you know, JavaScript,
Angular, et cetera, that really don’t
play well with SOAP. Or the way the
system was set up, it’s not very easy
to give you access. If you’re like, hey, can I have
access to this account service? I’m like, sure, give me three
days reach out to network guys to get your account
provisioning. And then oh, by the way,
here’s this really crazy WSDL that you have to use if you
want to just get Bob’s account information from
his email address. So at Citrix were looking
for a way, both internally and externally, to allow
developers, partners, vendors to access this
information without having to jump through all these hoops
because it provides a bad API– or I’m sorry, a bad service
experience like Greg talked about. So we started– we looked at– we researched several
different APIs platforms. And we decided on Apigee. We created a simple POC in
order to check out the features, make sure these guys knew what
they were really talking about, and if it would
be something that would be a good fit for Citrix. And we decide to move
forward with that. Now, in production,
we have over 20 APIs. You can see them listed up here. We have single sign on account
APIs, contacts, support cases. There is actually a
Salesforce API you see listed. That’s interesting. Behind the scenes, that’s
not even our service. So we use Salesforce
for our CRM system. And they have SOAP
services that allow us to access our customer data. So we put API management
Apigee on top of that in order expose that data out. And like I said, all
of our APIs are used use both internal and external. And it’s a simple platform. So the developers consuming
them, internal and external, they love it. We give them a key. We sign them up. It’s real quick and simple. And they’re off
the ground running in a very, very
short amount of time. And then our internal
developers who are actually configuring Apigee and
these services, you know, it’s real simple to use. It’s easy to issue keys. It’s easy to do a lot
of different things. So I’m going to talk about– Citrix is one of our first
big use cases that we had. So to give you a little
bit of background, we have an e-commerce
platform that we’re using to sell product
to small businesses and also issue trials. One of the problems with this
was that for the license keys, they had to be uploaded
manually by the business. And any time we’d run
out of stock on one, someone would get an email
saying, hey, you know, XenDesktop, we’re
out of product keys. You know, and someone would
have to go and upload new ones. And those were
generated internally. And it was not a simple process. So the business came
to us and said, hey, is there a better way
that we can do this? Because this was
almost one person’s full time job to manage
these product keys and upload them because
we had something like 50 different products in
the store, 50 different skews at least. So that was our first
use case, right? And this vendor
said, oh, we have a system where we can make calls
after the order is complete. We’re like, great. That’s terrific. However, here is
this crazy schema that we’re going to send you,
and you have to use this schema and accept it. And that’s how it is,
just like Greg was saying. They’re big enough. They’re like hey,
here’s our contract. You have to abide by it. So we didn’t want to do that. And Apigee was the perfect
solution to this problem. So if you look up here
on this next slide, you can see how our solution
was actually set up. So at the bottom you could see
the external e-commerce site. They send us custom
ridiculous schema. We transform that. And then we send it over to you. You could see the Citrix license
WCF service that’s a legacy .NET service that’s been around
at the company for quite some time. So to expose that,
all we had to do was configure Apigee, create
an XSLT that I created. And it takes only
the values that are needed for the service. It sends it the service. The service brings
back the SOAP response, converts it back into the
vendor schema, and sends it off. Then once we had that up
and running, our trials team heard about this and
said, wow, they said, you guys have an API now? We’d love to use that. However, the trials team,
as you’ll see in a bit when I show you
guys a demo, they have just a simple
front end site, and they have some front
JavaScript developers, and they need that
information in REST. And we said, that’s great. Here you guys go. Now there’s a REST front end on
it, as well as returning JSON. Does the same thing. It hits the same
service on the back end. But on the front end, you know,
it’s really easy for these guys to use. They send us the
information in JSON. We create the license
key, and send it back. And then, finally, we
have SOAP consumers who just send us the actual
schema that our service uses. And we sent it back their
keys in that format. So we have one back
end service that’s exposed over three
different protocols. When we deployed all
these different solutions, there was no back end
service change needed. All of this was done
through configuration on the Apigee side. Very simple to use. Developers were like,
here’s your key. There you go. And they’re off and running. So just to show you real quick– I don’t even know if
you guys can read this, but on the left hand side you
could see that vendor schema. And that’s not pretty. That’s what our vendor said. Here you go. You go write a
service that takes it. We didn’t want to have
to deal with that. And you can see that there’s
a scroll bar up there. So that’s not even
their entire schema. They send every single
piece of information they have about the order. In the right hand side ,
you see our Citrix schema, which is only about eight
to 10 different inputs, a couple of different skews. And they’re off and running. And that’s it. So Apigee really helped us
move from this crazy schema to our simple schema,
send it to the back end. And then, also,
on the trial site, those guys just send us JSON. And we convert it to
the schema you see here. And it gives them the
result they’re looking for. So real quick, I’m going
to show you guys something. We switch. There we go. So as much as I’m
sure Prithpal would love if I messed
with his account, I’m going to log out of
his account real quick. Yeah, no problem. And then I’m going to
sign in to my account. Cool. So looks like it
did not like that. OK. So real quick, I’m going
to open up our proxy. And I’m going to go to
the trace tab real quick. So this was actually shown
this morning for the keynote, for anyone that was there. This is actually the
Apigee trace screen. So what this allows
you to do is this allows you to run a Live Trace
and watch an API call as it comes through, inspect
the data, and see what’s going on, if there’s
any kind of problems. As developers, we really like
that because if one of our end users reports a problem,
this makes it very easy to determine if it’s something
in the Apigee configuration, or if it’s something in
our back end service. We can inspect the data– see what’s going on. So I’m going to start that
real quick in this tab. And then over here, I’m
going to go to Now I’m going to
go to downloads. And I’m going to
click free trials. So I’m going to choose the– let’s go with XenApp. And then I’ll
click Download Now. So we’ll start out–
there’s actually four APIs that our trial
department is using here, all in this one page. So the first thing
we have here is says enter your email address. And we will send
your trial license. So I enter my email address. And this is where the
first API call takes place. What it’s doing
is it’s checking. It’s calling API
and saying, hey, does Adam Brancato have
an account with us? And it did. It found my account. If it didn’t find my account,
what it would have done is, instead, it would have
displayed a different screen, which has very compact number of
fields to create a new account. The trials
department, they said, we don’t want to direct
somebody all the way to the site in order to go through
the full account screen because that’s potentially
going to deter them from coming back and
downloading the product. So instead, they created
a compact screen here if they don’t have an account. So I’m going to
log in and pretend that I’ve read and accepted
the end user license agreement. And hit Send License. So now what this is doing, if
we go over to this tape here– everything’s working
as expected– we should see this call come through. And there it is. So that’s actually in progress. As is creating the
key, it’s going out to the back end service. This lags a bit behind
on what’s going on. And then you can see here
that it says, hey, here’s your license key. And it’s created my free trial. So let’s go back real quick. And we can take a look
at what’s going on. So basically what Apigee allows
you to do is, in real time, we can take a look
at this request. This is where it verified our
API key that we use to send it. Then there’s some basic
authentication shapes in here where we inject some
values into the request before we send them off to
our actual back end service. And then, on the bottom
here, anything up top here, is the request pipeline before
it’s called our service. And then down here is
the response pipeline, everything that gets
executed on the way out. And there’s error checking in
there, formatting, et cetera, makes it very easy to see what’s
going on inside of your APIs as they’re executing. And if we go here, this
is the XML to JSON shape. And you can see here’s
the JSON that’s returned. If you go back one shape,
you can see here’s the– visible up there, sort of– you can see here’s the XML. It’s kind of what they showed
in the keynote earlier. This is actually the response
from the server in SOAP format, but we converted over to that
JSON format that we send back. Very useful. One of the last things I’ll show
you is analytics and reporting. So one of the features that
we find extremely useful is Apigee has a great
number of built-in reports. So if we go to– so by default, Apigee going
to give you proxy performance. For example, it’s going to give
you a bunch of default numbers. I’ve got to change
the date because this is an older environment. Here we go. So this will give you things
like average server response time, amount of traffic
that came through the proxy, et cetera, et cetera. And you could see
that, for example, you know, for this period we
had 2.3 million calls. This is all great. But every so often you need some
of your own custom analytics. We had a problem
a couple of months ago where one user, for example,
was causing a lot of traffic on our one proxy,
and we needed to know exactly which user that was. And those built in reports,
they give you high level overall the total number. So what we needed is traffic by
the proxy and by the operation. So we created this very
simple customer report. This took all about 15
minutes maybe to create. And you could see this gives us
here a quick drill down into, OK, over that time
period, here’s all the different
services that were called. But we wanted more. We wanted to know exactly
which operations and who was calling at
because we had someone that was causing a heavy load. So through this custom report,
it’s very simple to take, for example, the contact
service, click on that. And this is going to
show me, OK, here’s all the different operations. Here’s the different paths. And then I can take the
Person Details, for example. I click on that. And now it’s going
to tell me, OK. Here’s the CWC Control
Center, and Control Center V2. That’s where the majority
of your traffic is. And this report also– it’s funny that
they’re listed here– is actually, we– they wanted
us to give them a new API key. They said, we don’t want
to use the old API anymore. Can you give us a new one? We said, sure,
that’s not a problem. They said, can you
turn off the old one? We said, we can, but
are you sure that none of your other
applications are using it? And they said, oh, yeah,
you can turn it off. Nobody’s using it. We ran this report,
and they were wrong. We said, no, no, if you look
right here, you could see V2, you have 1,100 calls, for
example, or whatever it was. And here you have 56,000. So this really helps
validate a lot of data, examine your traffic,
and see what’s going on. So lastly, can we switch
back to the slides? Cool. So overall, I just
wanted to talk to you in general about a
lot of the benefits that we at Citrix find
from the Apigee solution. Consistent APIs is a facade,
you know, disparate backgrounds. You know, I assured you
guys, we have a whole lot of SOAP services, and then
we have a lot of new services that are web API
services, et cetera. So Apigee allows us to
use them to sit on top, call out to these
different services, and expose them over whatever
protocols that we want. In fact, one of our services,
the single sign on service that we have that
gives out tokens, several third
parties and vendors use this to authenticate
against the Citrix users. And they said,
well, is there a way we can also get like, someone’s
first name, last name, and about five or six other
pieces of information? So we have a second
single sign on API that actually authenticates,
and at the same time calls another service, but
combines all that data into one response. We didn’t have to write
additional services on the back end. All we needed to do
was configure Apigee and say, hey, make a call
out to the second service. And Apigee, they allow us to
have our developers focusing on actually writing
these back end services, as opposed to, OK, now I have
to figure out a new security implementation, like
Greg was talking about. Or if I wanted to consume
that schema I showed you guys a couple
of slides ago, I wouldn’t want to be the
guy that had to do that. Apigee also, they took away
our need to manage these users. We manage them now
through the Apigee system. Before, we had to create
Active Directory accounts in some situations. In others, there was
databases of passwords. And canceling one was
a whole other hassle. Apigee is like, we got it. We’ll take care of it for you. Makes it easy for us,
and much, much easier for developers and consumers
because it’s easier for them to get on board working in
a couple of minutes almost. Lastly, they can secure
and obfuscate data for us. You guys didn’t see
it in this service, but we have a vendor ID that we
need in our back end service. And it would be really
silly for me to say to you as an end user, hey, your
idea is 1, 2, 3, 4, 5, please send me that
in every request. So what we can actually do is
be associated with their API key inside of Apigee. When Prithpal was shown
you guys the screen where he was approving
the developer, there were some key value
pairs at the bottom. So we set that up in there so
the end user actually doesn’t need to know that value. We pull it from there develop
project inside Apigee. And finally, I showed you guys
it has traffic management where we can see what’s going
on the different servers, and we can run
reports, analytics, and see everything that’s
going on from the Apigee side with our APIs. So on that note, I’d like
to bring Greg back up. Talk about a couple
of last minute things. GREG BRAIL: Yeah, I think I have
one or two last minute points. We’re almost out of time. First of all, as we
saw, I mean, Adam did a great job of showing
real life production traffic, which I thought was awesome. There’s no fakery there at all. [APPLAUSE] And so, I really
appreciated that. But I mean, really,
consistent message here. Think about developers. Put yourself in the
shoes of your developers. And build APIs that you think
they’re going to want to do. Many people, sometimes
they question the value of self-service. But we just saw an example of
where, by enabling self-service for developers,
Citrix is able to make things a lot more
efficient internally. So thank you all for coming. Thanks for staying
around the conference. And we’ll see you all later. [MUSIC PLAYING]

One thought on “Using Apigee Edge to create and publish APIs that developers love (Google Cloud Next ’17)

Leave a Reply

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

Back To Top