[MUSIC PLAYING]
DRISHTI GUPTA: Hello, and welcome to Google Cloud.
I'm Drishti, and I have Michael with me.
We are solution engineers for Google.
Today, we will show you a demo that
depicts one way to modernize your legacy Java applications
using Anthos on Google Cloud.
Java is the most common run time when
it comes to deploying applications
in production environments.
Consequently, it comes as no surprise
that most companies are intent on protecting
their past strategic investments in Java, including
retaining internal Java developer expertise.
There are hundreds and thousands of existing enterprise Java
applications.
Most of them are actively maintained, but have not
been actively developed.
Patching and maintenance of the application
and its infrastructure continues to grow.
The only way left to modernize these applications
is to rewrite them, which is tremendously time-consuming.
At Google Cloud, we have identified
few different solutions to address the pain points,
and today we will be showing a demo of option number one--
modernize with containerization.
When you onboard Java application to container
with Anthos, an automated development
process with a software pipeline,
you'll see a 37% TCO savings instantly.
Furthermore, automating testing and refactoring
the application, one starts to see an additional 78%
in TCO savings.
First, let me provide you with a few anecdotes
so that the demo resonates better with you.
Hipster Shop is a company who has a modern online boutique
website running on Google Cloud.
They also maintain an on-premise VMware environment
that is primarily hosting legacy applications, most of which
are no longer getting new features
and are simply keep-the-lights on apps.
One such application is the legacy CRM Java
app, which they would like to modernize and run
on Google Cloud.
Hipster Shop's Google Cloud environment--
they have Anthos clusters running on Google Kubernetes
engine to host their modern applications.
They utilize Anthos configuration management
to keep common Kubernetes configuration and policies
in sync and up to date across the clusters.
The source of truth for these config files and policies
must reside in a Git repo.
So Hipster Shop leverages their own instance
of GitLab running on GKE.
They also use Anthos Service Mesh on their production
clusters to collect mesh telemetry, define service level
objectives, and secure communications
across the microservices that make up their applications.
In their on-prem VMware environment,
Hipster Shop uses vCenter Server Appliance
installed on an ESXi host to manage their inventory
of virtual machines.
To begin modernizing the apps running on VMs,
Hipster Shop's operators needed to set up Migrate for Anthos
to snapshot their VMs and generate their container
images.
The legacy CRM Java application is
deployed on a WebLogic application server.
They also installed the WebLogic server Kubernetes operator
on that Anthos cluster to automate the deployment
and management of a WebLogic environment running
on Kubernetes.
Let me now show you these components running
live in VMware and Google Cloud platform.
Hipster Shop's VMware ESXi host is
running on an on-premise bare metal machine.
They manage and configure their VM inventory
through the vCenter Server Appliance.
The legacy CRM Java application that Hipster Shop's operators
will modernize is running on Red Hat Enterprise Linux VM
that you see here.
WebLogic server is installed on the virtual machine
and provides the WebLogic application server
that the legacy CRM application runs on.
Here's the front end of the Hipster Shop's legacy CRM Java
application.
The application follows standard Java Enterprise Edition design
principles.
For example, the domain and the facade layers
of the application utilize Java Spring Framework
and the Java messaging service.
And the presentation layers use JavaServer Pages and Faces.
Let me now show you Hipster Shop's modern cloud
infrastructure running on Google Cloud platform.
Hipster Shop's modern online boutique
is running on two Anthos Kubernetes clusters,
staging for testing and production.
These clusters will also host the legacy CRM application
after the migration from VMware.
Both of these clusters run on Google Kubernetes engine.
But with Anthos, Hipster Shop can
have clusters running across multiple cloud and on-prem
environments, such as AWS or VMware,
and they will be viewed and managed
from the Google Cloud console.
There is also a separate Migrate for Anthos processing cluster
that will run the migration of the Java application VMware
without having to worry about production applications being
affected.
Finally, you will see Hipster Shop's GitLab cluster
running on GKE to host their Anthos configuration management
repo.
I will now pass it off to Michael,
who will play the role of a Hipster Shop's operator
and will modernize the legacy CRM Java application using
Google Cloud's Anthos solution.
MICHAEL INTINDOLA: Thanks, Drishti.
I will first use Migrate for Anthos
to containerize the Hipster Shop legacy CRM application
so that it can be deployed to the Anthos clusters
running on Google Kubernetes Engine.
Migrate for Anthos uses the [? MQCTL ?] command line
interface to define the source and the destination
of the migration and to kick off the migration process.
As you can see here, I've already
set up the VMware environment as the source of the migration.
To begin the migration of the legacy CRM application,
I first create a migration plan using the [? MQCTL ?] command
line interface.
The migration plan will provide details such as the VMware
virtual machine that hosts the source application,
and where the new containerized images from the migration
will be stored.
Migrate for Anthos is able to determine
what files from the virtual machine
are needed to produce a containerized image
of the source application.
I only need it to specify the directories that should not
be included in the migration and the directories that
contain data that should be persisted
to a persistent volume.
When I finish running this migration plan
on the Migrate for Anthos processing cluster,
a set of artifacts are automatically generated for me
and stored in a Google Cloud Storage bucket.
I can download these artifacts to my Cloud
Shell or local machine.
These artifacts include a Docker file
to update my source application's container
image, a persistent volume on a Google Cloud persistent disk
that contains my source application's data,
and a Kubernetes manifest that I will
use to deploy my application to a Kubernetes cluster.
In the Docker file artifact, I can
see that the Migrate for Anthos runtime
is used as the base image, and it's
combined with a non-runnable base
image that contains a replica of the source virtual machine.
I can also make updates to packages in the container
and can upgrade the Migrate for Anthos runtime
in the future for new releases or bug fixes.
I can make changes to this Docker file
as I would to any other Docker file.
I make the changes, rebuild the image,
and push to a container registry,
such as Google Cloud's private Container Registry.
In the Kubernetes manifest file that
was generated from my application,
I have a stateful set, with Hipster Shop's Legacy CRM
container image specified in the image field.
The WebLogic Admin Console and the Hipster Shop legacy CRM
are exposed on port 7,001.
So I also expose that port on the source application's
container.
A load balancer service is also defined so that the application
is accessible from a browser.
Finally, there is a persistent volume
that specifies the Google Cloud persistent disk, which
contains the Legacy CRM migrated data and a persistent volume
claim that mounts that volume to the Kubernetes container.
To deploy the Hipster Shop legacy CRM application,
I apply the Kubernetes manifest file to my staging Anthos
cluster, where I will be able to test the application's
functionality before releasing the application in production.
Once the deployment is complete, I
can navigate to my Kubernetes services
to find the end point for my Hipster Shop legacy CRM
application.
It seems like there is something preventing the application
from loading.
Luckily, I know exactly what the issue is.
By default, all new applications on the staging and production
clusters have a Kubernetes network policy
that prevents external traffic from reaching the container.
This network policy is defined in the Kubernetes configuration
file that is stored in Hipster Shop's Anthos Config
Management repository.
As Drishti explained earlier, Hipster Shop
is using their own instance of GitLab
running on GKE to host their Anthos Config Management
repository.
This repository contains Kubernetes configuration
and policy files that are automatically
applied to Hipster Shop's staging and production
clusters.
And the configurations and policies
are kept in sync with this source of truth repository
to prevent any unwarranted deletions or changes.
The Anthos config management repository
is structured in a way that allows
me to apply configuration and policies
across all clusters at an individual cluster level
or at a namespace level.
If I go to the directory for the namespace that contains
the hipster legacy CRM application,
I can open the network-policy.yaml,
and I'll see the policy that is currently preventing me from
accessing the Hipster Legacy CRM application.
I will make a change to this configuration file
to allow all external traffic to reach my application.
And I will commit my change to the repository.
I can now go check if my configuration took effect
by refreshing.
Great.
I can now access the Hipster Shop legacy CRM.
Only this time, it's running on an Anthos Kubernetes cluster.
The network policy change that I made in the Anthos Config
Management repository was almost immediately
synced across my staging and production clusters.
After testing the Hipster Legacy CRM in the staging environment,
I can promote the application to production
to begin taking advantage of the rich feature
set of Anthos Service Mesh.
Anthos Service Mesh provides traffic management,
observability, and secure communication
across all the services running on my Anthos clusters.
From this single pane of glass, I
am able to view the 10 micro services that
make up Hipster Shop's modern online boutique website.
But I'm also able to see the Legacy CRM that
was just migrated from VMware.
Anthos Service Mesh automatically
proxies all requests between services
and collects a standard set of metrics
without having to make any changes to the application
source code.
I see those metrics displayed in this table,
and I will see them across many of the other Anthos Service
Mesh screens, as these metrics help gauge the performance
of my application services.
Another helpful view in Anthos Service Mesh
is the topology view, which, again, shows the same services
that are running on Hipster Shop's Anthos clusters,
but in a graphical format that highlights
the inbound and outbound connections of each service.
And I can see here the Hipster Legacy CRM
service that I just deployed.
If I click on the service, I will
see this set of standard performance metrics displayed
in the widget on the right.
Now as an operator, my job requires
that I keep all of Hipster Shop's services
running across the staging and production clusters
at an optimal state.
You might ask, what is an optimal state?
And the answer is that it really depends.
Each service is different.
There may be some services where slight degradation
in performance will negatively impact the end user's
experience, while other services may not be as delicate
and slight performance changes will go unnoticed.
With Anthos Service Mesh, I have the ability
to set Service-Level Objectives, or SLOs, for each service
so that I can proactively monitor Hipster Shop's
applications' health and ensure that end users are not
having a negative experience.
I've already set up an SLO Hipster Shop's legacy CRM
application.
Let's take a closer look at how I defined this objective.
The metric I'm interested in monitoring and maintaining
for this service is latency, or how long it takes the Hipster
Shop Legacy CRM service to respond
when it receives a request.
Next, I specify my latency threshold.
That is the maximum amount of latency
I'm willing to accept for my service to be considered
at an optimal state.
I set the threshold to be 20 milliseconds.
I then set the time period I want
to use for evaluating the SLO to be a rolling one-day period.
Finally, I choose a performance goal.
With my goal set to 90%, I am saying that the Hipster Shop
Legacy CRM service latency should
be below the threshold of 20 milliseconds 90% of the day.
So that wraps up our Java application modernization demo
with Anthos.
In this demo, you saw how a Java Spring application
was migrated off of a virtual machine running on VMware
to an Anthos Kubernetes cluster running on Google Cloud's
Kubernetes Engine.
You saw how a Kubernetes network policy or any other company
good reason or policy file can be
synced across multiple clusters in a matter of seconds
using Anthos Config Management.
And finally, you saw how an operator can use Anthos Service
Mesh and the observability metrics
it provides to set service-level objectives
on their containerized services.
Thank you, and we look forward to showing you
more application modernization tools
on Google Cloud in the future.
[MUSIC PLAYING]