KEITH DANEKIND: Hi, I'm Keith Danekind,
and I'm a customer engineer on the Apigee team.
Today I want to show you how Apigee
can help modernize a legacy application to enable
new digital experiences.
We'll look at a demo where I'm going
to move a service from a legacy environment to the cloud
without disruption and add a bunch of other benefits
along the way.
Here's a diagram that describes the problem
I'm trying to solve.
There's a service running in the legacy environment,
and I'd like to move it into Google Cloud.
I'd like to do this without disrupting the existing
applications and establish a pattern that I can
use for moving future services.
I'll start by building a facade in Apigee.
I'll make well-designed REST services that
have consistent interfaces and security,
and I'll map those to the back-end services.
I'll map the basic CRUD operations--
Create, Read, Update, and Delete-- to the HTTP
verbs POST, GET, PUT, and DELETE.
I'll use Apigee's routing features to route traffic
to the right back-end services, and I'll
use Apigee to manage API keys for each application
and create policies in Apigee to manage the flow of traffic.
Here's the goals I have for my project.
First, I want to move the legacy service
to the cloud with no downtime.
I want to start by testing the cloud service by routing
10% of the traffic to the cloud, make sure everything's
working the right way.
I want to get visibility into which applications
are using the service.
Today there's a single URL, and we've
got some logs and things like that,
but I don't know which application is sending
in traffic specifically.
I'll add API keys in Apigee that'll identify
individual applications.
I want to add some rate limits to protect the services.
We don't want one application calling too much.
We'll add call quotas based on the partner relationship,
so different partners get different quotas.
I want to remove some sensitive internal data from the partner
applications.
I need to add support for XML-formatted data
to support some of the legacy clients.
If they request XML, we'll return it.
I want to make it easy to onboard new applications
in the future and get ready for the hundreds of partner
applications I know are coming.
And throughout all of this, I want
to establish a reference architecture
so that this can be the pattern for moving future services.
Let's look at a demo and see how to build this in Apigee.
Here in Apigee, I've configured two target endpoints,
one for each of the different back-end systems,
the legacy system and the cloud system.
I also have a URL here where it will
be listening for traffic to come in and be
routed through Apigee.
This is where I manage the request and response flow.
I'll put different policies in here
to affect how the traffic flows.
The first one checks for an API key.
Next is a Spike Arrest to prevent too much traffic
from coming in.
Then there's a business-related quota
that's going to limit the number of calls
depending on who's calling.
The next two are what we're going to use specifically
for routing.
Apigee has a key value map, and inside of there I
store important values.
I've put a probability in there that I'm
going to use to determine how much traffic goes to the cloud
and how much goes to the legacy system.
So this looks up that value, and then
we're going to have some JavaScript in here to randomly
set a flag, and that flag will determine
whether we get routed to the cloud or the legacy system.
Let's look at how that works.
In this JavaScript policy, we see there's
some code referenced here.
So here's our code for generating a random number
and then checking to see if it's past the threshold
and setting a flag to true if it is.
So testGroup will be set to true if we're in the test group.
Down here we have some route rules.
Route rules let us configure where the traffic should
be routed in Apigee.
You can have multiple different back ends,
and you can route to different ones using some of these rules.
I've got two back-end systems in here.
I have the cloud system and the legacy system.
If the condition testGroup equals to true,
this rule will be true and we'll be
routed to the cloud back end.
That gives us a 10% chance, in this case,
of being routed to cloud.
There are a few more goals I had for this,
and we can see those on the response side.
One goal was to remove sensitive data,
so there's a particular field in there that I want to take out.
I've got some JavaScript in here to remove a sales group,
so there's a particular field called SalesGroup.
I want to delete that from the JSON that comes back.
If there's an accept header on the request
equal to application/XML, this policy will fire,
and it'll convert from JSON to XML
and return the data in XML format
to those clients who need it.
I can build a custom report in Apigee
to see how much traffic is going to the legacy environment
and how much is going to the cloud.
I can click through on each metric and get more details.
This shows me traffic from each of the applications,
and I get an idea of who's sending
the traffic into the system.
One of the other goals was to make it
easy to onboard new partners.
I've created a developer portal in Apigee,
and this provides complete self-service
for people who want to write applications using
the APIs that I've provided.
They can come in here.
They can read documentation about how the APIs work.
They can try them out, and they can
sign up and get credentials.
That was a quick demo about how we
might use Apigee to modernize a legacy service
and move it up to the cloud, and add a bunch of stuff
along the way.
Thanks for watching today.
[MUSIC PLAYING]