LAUREN PRICE: Hey, everyone.
My name is Lauren Price, and I'm a networking specialist.
And today, I'm going to walk you through a demo of a new feature
that we have out with Apigee and the use of PSC.
But before we jump into the demo,
I want to walk you through a couple of slides
so you can get an understanding of what PSC is, what Apigee is,
how it's used, and the architectural patterns
that we're working with today.
So Private Service Connect is a new method
of routing within Google Cloud that
allows private consumption of services across VPC networks
that belong to different projects or organizations.
It can be used to access Google APIs and Services or managed
services in another VPC network.
Customers using Apigee as their API gateway
to secure their APIs can now make use of PSC
to provide access patterns to and from the Apigee platform.
So today, I'm going to walk you through the whole process
of setting that up.
The Apigee runtime runs in a Google-managed VPC
that can be peered with a customer VPC.
Traditionally, a network bridge provisioned along
with a load balancer in the customer VPC
was required to communicate with Apigee.
But now, you can use Private Service Connect, or PSC,
which we'll refer to it as, in the form of a PSC Network
Endpoint Group, or NEG, to connect
to Apigee in a northbound traffic pattern.
Apigee is exposed outside of the Apigee Tenant VPC
through a service attachment.
PSC NEGs are configured to point to these service attachments,
and API calls from the internet can
be routed through the global HTTPS load balancer and the PSC
NEG to Apigee.
And when you have multiple Apigee instances
in different regions, you can use the global external HTTPS
load balancer and PSC NEGs to route traffic
to the nearest Apigee region, or seamlessly
failover from one region to another
in the event of some kind of regional outage.
As part of the demo, we'll walk through a number
of components that have already been built ahead of time.
So this is just a briefing of what those components are.
The private service access peering range
has already been allocated for Apigee on the default network.
KMS has already been set up in the appropriate regions
that Apigee will be running in.
We have already built the external HTTPS load balancer
forwarding roll for port 443, protected
by an SSL certificate.
And lastly, we have test clients running
in the us-east1 and us-west1 regions.
One last detail that I wanted to touch on
is we are using a commonly used open source
domain called nip.io.
We use that for a lot of our Apigee demos.
We're using that as our domain in this demo.
It's going to act as a wild-card DNS for any IP address,
and this is so we don't have to purchase our own domain
or own our own domain.
Just for demo purposes, like I said.
So let's jump into the demo.
All right, so here we are in the Apigee Setup screen.
This is the wizard that you will use to provision Apigee.
This is what it will look like for first-time users of Apigee.
So if you've never provisioned Apigee before,
this is what you'll see when you hit the landing page.
So we're going to go ahead and click Set Up Apigee.
And we will input the name of our project that we are using.
And for this particular demo, we are using the Pay As You Go.
If you do want to do any kind of test of Apigee,
you can choose evaluation, and that will give you
a free evaluation org.
But for now, we're going to use Pay As You Go.
So the APIs are already enabled in our project.
We went and did that ahead of time.
If you've not used Apigee before,
these are all of the APIs that you
will need to enable within the Google Cloud Console.
So then we will go ahead and click
into Edit for the Apigee organization,
and start to set that up.
All right, so here we are in the Edit screen for the Apigee org.
It's going to ask you to set up an analytics hosting
region as well as a Cloud KMS location and encryption key.
So we'll go ahead and set up the analytics hosting region.
And then we will pick the appropriate encryption key
region.
And we already have our pre-allocated, already created
encryption key that we spoke about before.
So we will go ahead and we will create the organization here.
And this will run for about five minutes.
So we'll come back whenever this is done
and move on with the demo.
All right, so we are back.
The Apigee organization setup is complete,
so we're going to go ahead and move on
to set up the networking.
Now, for this demo, we are using the default network
that exists within our project.
And we have already gone ahead and set up
this peering ahead of time, but this is the private service
access peering range that we spoke about in the slides prior
to the demo.
This is going to be an IP block that you
allocate for services that are using private service access.
Even though we're using private service connect for the access
method, Apigee still requires you
to set up a peering connection for the time being
to be able to access services through Apigee.
But just know that we're not actually going to leverage
that peering connection.
We're going to use the private service connect NEG
that we set up to actually access the Apigee environment.
So let's go ahead and connect to that.
And we will move on to setting up the Apigee runtime.
Most likely, you will pick the region
that you picked for the analytics
when you set up the actual Apigee org.
So we'll scroll down and click us-east1, where
we set up the analytics region.
Now, for the IP range allocation, that peering range,
or that private service access range that you allocated prior,
we're just going to pick a smaller CIDR range out
of that block to specifically allocate to Apigee.
If you pick Automatic, Apigee will pick a range
for you out of that block that you allocated,
but if you want to actually pick your own Custom range out
of the block that you allocated, you
can go ahead and click Custom and input your own choosing
of an IP range.
And last, we will pick a KMS key to use as the disk encryption
key.
Again, we already created this, so we'll go ahead
and we'll pick the key that we created in the us-east1 region
and click CREATE RUNTIME.
Now, this step will take probably
about 45 minutes to an hour.
So again, we're going to cut here,
and we will come back when this runtime has finished creating,
and we will finish out the rest of the wizard setup.
All right, so we have finished our runtime set up,
and we are ready to finish out the wizard with setting up
the Environment and the Access routing.
So we'll go ahead and we will click Edit for the Environment.
And there are a number of specific names
that you can choose here, again, custom to your own environment.
We're going to leave the defaults in,
so Environment group name we'll keep as dev.
The Environment group hostname is essentially the domain
of your Apigee instance.
And so this is where our nip.io domain
is going to come into play.
The hostname that we put in here is
going to be the IP address of our external load
balancer.nip.io.
And this is just going to wildcard that domain
so we don't have to purchase it or purchase anything
for the domain.
Environment name, we'll keep the default.
So lastly, we will scroll on down to Node settings.
This is what handles the autoscaling of Apigee.
For the purposes of the demo, we are
going to keep scaling very, very small
so we don't have to pay a ton.
So for customers in production, this
is probably not an advised scaling settings for you.
But for demo purposes, this is great
so that you're not going to scale at all.
You're going to want to do some proper capacity planning
to understand how many nodes that you'll probably
want to scale up to.
So we will create that, and this will run for a minute or two.
So again, we'll cut, and we'll come back.
All right, lastly, we will set up access routing.
And this is specifically where you're
going to pick whether or not Apigee
is going to provision with that managed instance group
that we spoke about during the slides or with PSC.
So specifically, you want to pick No internet access
to use PSC, and Apigee will create the service attachments
needed for you to be able to connect to PSC NEGs.
So we'll finish that out, and your Apigee organization
is ready to go.
So let's go ahead and open the Apigee Console
and see what we're working with here.
All right, so here you can see that we are in the Apigee
Console, and what we're actually going to do now
is we're going to go through the same setup process
to set up another Apigee instance in the us-west region
so we can show how the multiregion failover will
work during the demo.
So we'll click through a couple of settings here,
and we'll get that process kicked off
to actually provision another Apigee instance.
There we go.
We have it kicked off.
And again, we will let this run for a while.
We will cut, and we will come back when this setup is done.
OK.
So we are back, and we have both regions' setup complete.
You can see that our service attachment
URLs have been provided to us already because we
picked the proper PSC setup.
So we are going to now start the process
of creating our NEGs on our back ends for our load balancer.
So I made sure to copy down those service attachments that
were in the Apigee portal, and we're
going to jump now over to the Google Cloud Console.
So you can see we already have our load balancer set up.
You can see the IP address is the same
as we put in for the domain.
We have the cert here.
So we're going to go ahead, and we're going to edit this.
And just to show you what we have going on here,
you can see where our protocol is HTTPS.
We have the IP address.
We have the cert that we already set up ahead of time.
So next, we will go in to the back-end configuration.
And right now, we already have an empty back end set up.
So we're going to go ahead, and we're
going to edit that so we can actually
change the back-end type to private service
connect network endpoint group, or NEG,
and we're going to go ahead and add the east back end first.
But we need to create it.
So we're going to name it.
We're going to copy and paste that service URL
that Apigee gave us and target that
for the service for the NEG.
Our network, again, is the default network
that we're using.
And the subnet, we're just going to go ahead and use
that default subnet for the region that we're in.
So that's our east region.
And now we're going to add our west region.
So again, create that NEG.
We'll name this the west NEG.
We will grab the URL that was provided
to us from the west region.
Again, same network, and we're going
to use the default subnet for the west region now.
All these settings, we're going to leave blank for now.
Again, in a production environment, would enable you
or would encourage you to enable logging and also
set up Cloud Armor to be able to protect those endpoints.
But for now, we're just going to leave all those blank,
and we'll go ahead, and we will update those back ends.
Next, we will move on to Routing rules.
And you'll see we're not doing anything special here.
We're just going to leave the default for the URL map
and just use the single default back-end service.
So we're going to go ahead and update that,
and we will let it spin for a little bit.
Again, take a couple of minutes.
So we'll cut, and we'll come back,
and we will actually jump into showing you what's next
in the Apigee Console piece.
All right, so while we're letting that spin,
we're going to jump back over into the Apigee Console,
and we are going to set up an API proxy so
that we can actually show you what's
going on with an API call.
So we have a simple proxy that we have set up already
that is basically--
what it's going to do is it's going
to point to httpbin.org, which is an API that will essentially
take the call and return the headers for you.
So we're going to point to that API.
And what we're going to do is we're actually-- with this API
proxy, we are adding a header to what httpbin.org
is going to give us.
So we'll go here.
We'll jump into the Developer tab,
and we will show you that we are adding a specific header called
region.
And this is going to grab the region name that the Apigee
instance is located in, and it's just
going to return it in the form of the header.
We will point to some documentation
down below that will show you something that's very, very
similar to what this is.
You'll just need to edit some of the specific parameters
to get this set up.
All right, so we're back in the Google Cloud Console,
and we are actually going to test
some calls now from our clients that we have created.
So we're going to go ahead and jump into Compute Engine,
and we are going to SSH both into the east1
and the west1 clients that we have created.
So we'll go ahead and we'll get into these instances.
So we're in our east1 client.
We'll go ahead and we will make that curl call to our API,
and you will see that the region that the API has returned
is us-east1.
So now we will jump into our west1 client
and do the exact same API call.
And we'll see exactly that you get--
now that we're calling from the west,
because we're closer to our API, or our Apigee
in the west region, that we will get
a response from our Apigee region in the west.
So now, let's go ahead and let's take down one of those regions.
So we'll jump back into the Cloud Console,
and we'll go back into our load balancer config.
And to simulate an outage, we are
going to go ahead back into our back-end configuration.
We're going to edit that again, and we
are going to completely delete our west1 back end.
So this is just a simulate as if west1 has broken
or there is something wrong with the region.
So we'll update our load balancer,
and we will let this spin and give it
a minute to actually update and recognize
that the region is now down.
All right, so we see that our load balancer is finished
updated, and we only have one back end NEG
on that load balancer.
So we're going to go back into east,
and we're going to make that call again.
And you'll see that we're still getting a response from east.
Our clients are supposed to get a response from east.
Our east back end is still up.
But if we go over into the west, where we should normally
get a response from west, the expectation
is now that those clients will have failed over
to now use the Apigee instances in the east
because those west instances are no longer available.
So we'll go ahead and we'll make that call.
And you can see here right away that, indeed, our clients have
failed over to now utilize the Apigee instance in the east
because the west is no longer available.
So operations are not interrupted at all,
and clients will seamlessly make that failover
to point to the other region when their main region is down.
So that's all we have for you today.
Thank you so much for watching.
Don't forget to like, comment, and subscribe.
If you have any questions, please leave them below,
and we'll do our best to get back to you.
I hope you can get a chance to try this out
in your own environment, and we hope to see you again soon.
[MUSIC PLAYING]