CANDICE QUATES: [MUSIC]
Hi. I'm Candice Quates,
an Engineering Manager at VMware.
I'm here today with my colleague Paul Aly to talk about
building and running enterprise
grade Spring applications in the Cloud.
Spring is a wildly popular Java
development app framework
that provides a simple,
comprehensive and modular way
to build modern applications.
Modern app architectures can improve scalability and
velocity for developers but
implementing them can be challenging.
With a Spring boot architecture like this,
establishing process and technology to do
dynamic scaling of infrastructure take a lot of effort.
Many other things need to be taken care of,
such as service discovery,
configuration management, and energy in
the application lifecycle for security fixes.
All of this takes time away from building apps.
To make it simpler to
deploy and operate Spring applications,
VMware and Microsoft created
Azure Spring Cloud now Azure Spring Apps in 2019.
Let's take a look at a few of the things that can
make running enterprise Spring applications simpler.
Paul Aly is now going to show us how to build service
that is included with Azure Spring Apps Enterprise Tier.
PAUL ALY: Hi everyone. I'm Paul Aly.
As Candice mentioned, I'm an engineer with
VMware working on Azure Spring Apps Enterprise Tier.
Azure Spring Apps Enterprise Tier
really enables teams to build,
manage, and run their applications in the Cloud.
We're going to first explore that first phase
build and we do that with Tanzu Build Service.
Tanzu build service automates container creation,
management, and governance at enterprise scale.
It covers just using builders ability to find
stack and build back used
and processes building source code.
They provide the build packs that ran
against the application and
the operating system images
upon which applications are built and run.
Every new Azure Spring App assistance
comes with a default filter created.
However, let's go ahead and create our own builder.
There's a few fields here,
first we're going to give our builder a name.
Let's call this Hello Tanzu Build Service.
Now, we have two other options,
the OS Stack and Buildpacks.
First, let's choose our Buildpacks.
We can select from Java,.NET core,
Go, Node.js, and Python.
For our convenience we might like all five.
Let's say we know our organization only
uses Java,.NET core, Node.js.
It's like only those three.
This way we know which application types are
going to be built by the times you build service.
Now that we've picked our field packs,
let's go ahead and choose our OS Stack.
We have two options here,
we have base and full.
For most cases, base will be sufficient.
However, some people might need full.
Full is intended for Node.js and
Python applications with many native extensions.
Knowing that, we're going to select bionic base for
our builder because we know we don't
have many native extensions.
Let's go ahead and save that now.
The next part of builders are bindings.
Bindings allow Tanzu Build Service to inject
necessary configuration into our applications
to use other services.
Our new builder is still being created.
Let's go into the default builder to edit its bindings.
We see there are several bindings available.
We have Application Insights,
App Dynamic, Dynatrace, Elastic, and New Relic.
From here we can add new bindings,
edit existing bindings,
or move existing bindings.
For now, let's go ahead and edit
Application Insight bindings.
From here, we can edit the related
properties to the binding.
For Application Insights, we have
sampling rate and connection string.
Azure Spring Apps creates
applications like for instance for
us and provides the connection string.
We're going to leave that alone.
We can see that the sampling rate is set to 100 percent.
If you run, we are going to have this value.
Let's go ahead and edit this down.
You can see now we've changed it to
20 and we can save the binding to update the builder.
Now that we've explored
build service and builders a bit,
let's take a look at what a build looks
like from GitHub Actions.
Here we're looking at the build for
a JavaScript build app inside of GitHub actions.
As we scroll through, we can see
different output from the build process.
Here we can see bindings for
Application Insights that we just
saw on the build server side, but now in the build.
As we scroll, we can see
the different Buildpacks are going to
participate in the build process.
As you keep going,
you can see the output from each Buildpack.
Towards the end, we'll see
the gradle output building
our applications from the source code.
Finally, after we've built
the application and built the underlying container,
we'll see the output from Azure Stream Cloud showing us
the successful deployment and we'll get
the describing our application in its different traits.
Now that we've explored times you build service a bit
and we are we headed back to Canvas
Stock Spring Cloud Gateway.
CANDICE QUATES: Thanks Paul.
We're going to use
some API routes from
our Acme-Fitness Store application to
demonstrate functionality in Spring Cloud Gateway
available in Azure Spring Apps Enterprise Tier.
Here's our storefront,
we can see it's a catalog of
stuff that you can use for working out.
Here we have a catalog view of items.
Here's a yoga mat just selling
instant expert magic. That's quite funny.
Here in the Azure Portal,
Spring Cloud Gateway is providing the routing
for the frontend and
backend apps that make up the storefront.
Here are apps in the Azure Portal
and our landing page for Spring Cloud Gateway is here.
Here's the URL that goes out
to our service that we were looking at earlier.
Here's the route screen where we can see
the routes loaded into our instance.
If I scroll down a little bit,
you should be able to see the routes for catalog.
Here they are, catalog service.
GET products, and you can GET products with an ID.
Now to look a little further at these routes,
make them a little easier to see,
I'm going to go into API portal,
and in here, you can see all of
the routes provided by the application.
Let me scroll down a little bit here.
You've got the cart, and here's the catalog.
I'm going to scroll past the catalog a minute for
the frontend and the log in and the users.
I go back to the catalog.
Let's go GET products and try it out, and execute.
This looks like it succeeded. It did.
Here's our yoga mat.
It's made of magic. Now let's
go into the details of what we can do in
the JSON configuration for a route.
In here, if you can see,
we've got the predicates.
This is GET products over here.
I wanted to add a rate limiting filter.
This is the one of the commercial filters available in
Spring Cloud Gateway for Azure Spring Apps.
This rate limit right here will allow
only two requests for every 10 seconds.
Let's update that in the CLI.
Here's my route and I'm going to
update my route config here.
It's going to take a moment. We're going to go back into
the portal and refresh it in just a second.
It's really almost done.
It says it's running over here.
Here are routes in the portal.
I refresh, I should be able to see our catalog service.
It's right down here,
and it has a rate limiting filter enabled.
Awesome. There's many other plugins available here,
but these are just a couple I wanted to talk about.
There's are others.
Lots of things to rewrite headers.
There's circuit breaker and token relay as well.
Now another thing we get access to in
Spring Gateway in Azure Spring Apps is single sign on.
It's a standard OIDC compliant identity provider.
In here, I'm using Azure Active Directory,
but in you can use any OpenID
compliant at any provider you have.
It's just four parts of configurations,
the scopes, client ID,
secret and the URI.
Once you have that configuration,
you can go into the routing rules
and secure a specific endpoint.
If I can see here, the cart service is enabled with SSL.
We scroll down a little more and look
for the identity service for the log in.
The identity service is also SSL enabled.
I can show that by logging in,
and that is right here.
Let's go over to
the gateway and out to our fitness store.
Let's hit the "Login" button and it should just work.
We login. It's going to go back out and
back through Azure Active Directory
that I'm already logged into.
If I click the "Login" button again,
you can see that it's me here.
Very cool. I'm done here for now.
Paul, I'm handing it over to you to talk
about the Application Configuration Service.
PAUL ALY: Thanks, Candice.
Application Configuration Service allows us to
manage our applications
providing Kubernetes native resources.
It's similar to Spring Cloud Config server,
but underneath the hood, it's working differently.
Because it's providing Kubernetes native objects,
there's no client library necessary for applications.
Let's see how we can use
Application Configuration Service in Azure Spring Apps.
Here we can see the configuration
for Application Configuration Service.
Every configuration source requires unique name,
configuration patterns to load,
and a URI for the Git repository
containing our configuration.
Optionally, we can also provide a label to specify
our branch name and search path
as subdirectories in the Git repository.
By default, Application Configuration Service
searches the root directory.
Our patterns define what configuration
can be used by our applications.
Here, we can see that we've got
two patterns for catalog,
default and key vaults.
For an application to be able
to use these configurations,
we first need to find
its Application Configuration Service.
Here we can see the different app items
for app configuration service.
We can bind or unbind applications.
Here we can see that payment,
identity and catalog service are already bound.
Let's go ahead and jump in to catalog service.
Now from here,
we can go to configuration to see how it's configured.
You can see that there's
two different configuration options.
It's the same two we saw earlier:
catalog default and catalog key vaults.
Now let's take a look at
what configuration file that's
being used underneath the hood here.
Here, you can see we have a pretty
standard screen route configuration file.
We've got two profiles,
here we have key vault
and we also have the default profile.
In the default profile,
we can see that the management endpoint
has exposed all of the different actuators.
Now, let's take a look at how that configuration is
being used in the running application.
From here, we can see there's
two different config files being loaded.
We can see this first one is the key vault config file,
and over here we can see there's
the default config file.
Note you can also see the
same manager endpoints configuration
we saw earlier in our configuration file.
This is just being provided to our app
from Application Configuration Service.
Now, I'm going to hand it back to
Candice to go ahead and close this out.
CANDICE QUATES: Thanks, Paul.
If you'd like to learn more,
please go to via.vmw.com/asc-enterprise. Thank you.