TRAVIS WEBB: Welcome to Mainframe Modernization,
Accelerating Legacy Transformation
With Google Cloud.
Hi, I'm Travis Webb, enterprise solutions architect at Google.
Thanks for joining me at Google Cloud, next on air.
I work with our customers to help them solve their biggest,
most complex IT problems.
And today, I'm going to discuss mainframe modernization,
a new solution offering from Google.
This is an introductory talk.
So we're going to start out with an overview of the mainframe
ecosystem.
I'll then discuss mainframes' place
in our world today and some common ways
that our customers have tried, often with bad results,
to migrate off the mainframe.
Next, I'll introduce Google's offering
for mainframe modernization.
And finally, we'll walk through one customer's journey
as they migrated thousands of AS400 and mainframe COBOL
programs to run natively in Google Cloud.
Let's talk about the mainframe ecosystem.
First, let me give you a quick overview of the mainframe
market today.
The mainframe market is large.
It includes the costs of the machines themselves,
but also the fees paid for the usage of those machines
and licenses for mainframe specific software.
The vast majority of large companies
use mainframes to run critical business workloads.
And many of those applications have been built
over the course of decades.
Mainframe usage extends beyond the very largest companies.
And there are many thousands of mainframe systems still in use.
And each of these systems represents
an opportunity for Google and the customer
to come together to partner on a strategic transformation
of their business.
As commodity workloads are moving to the Cloud
at a rapid pace, mainframe workloads have lagged behind.
Let's talk about some of the reasons for this.
It's important to remember that, for most
of the history of computing, the idea of running
important business processes on a personal computer
would have you laughed out of the room.
The PC was a toy.
It was only in this current Millennium
that doing important things on individual PCs or servers
was taken seriously.
So how is the mainframe so resistant
to effective competition?
First, the IBM mainframe has an unbroken chain
of backward compatibility going back to the 1960s.
This durability has allowed the mainframe
to amass a large installed base of customers
and a reliable revenue stream for mainframe vendors.
And while the physical systems from the 1960s
are no longer in use today, many of the early programs,
written decades ago, survive to this day.
Second, our IT leaders have a tendency
to closely scrutinize the entrance costs when evaluating
a technology purchasing decision,
while much less attention is paid to the exit costs.
Leaving the mainframe platform was expensive and difficult.
And for many businesses, the cost of migrating still
isn't economically viable.
A proprietary ecosystem adds to the high exit costs
because many mainframe applications
rely on proprietary technologies that
are not available outside the mainframe ecosystem.
This combination of factors leaves current mainframe
customers with few viable alternatives.
If the mainframe vendor has a large installed base
of customers who can't leave, why should they
invest in innovation?
While much improvement occurred throughout the 20th century,
the relative advantages of the mainframe over other platforms
have eroded over time.
And today, mainframe customers now
find themselves at a technological and cost
disadvantage compared to their peers.
You no longer need a mainframe to run intensive processing
tasks, but if you already have one,
you're stuck paying for it anyway.
The interesting thing here is that these disadvantages
are widely recognized and understood.
But mainframe customers had few viable options
available to assist in migrating their mainframe
workloads to the Cloud.
With no new customers or developers
entering the ecosystem, mainframe vendors
de-emphasized investment in innovation.
Of course, around Y2K companies started figuring out
how to use commodity servers to run business workloads, instead
of mainframes.
Google, of course, was at the forefront of this movement.
It has pioneered many key data center infrastructure
innovations.
We serve customers all over the world with technology
that we've built into Google Cloud
and at a scale that simply would never have been possible
with mainframes.
Meanwhile, public Cloud is democratizing IT innovations
at an incredible pace.
And its explosive growth comes from companies
looking to leverage modern technologies
that their legacy vendors aren't providing.
It's no secret to anyone that legacy IT is expensive
and mainframe often tops the list.
But lots of things are expensive.
And high operating costs might be tolerable,
if you also got innovation and agility in return.
But with mainframe, you really end up with the opposite--
a static ecosystem that gets more and more expensive
and makes it harder and harder to innovate.
Customer expectations are increasing.
The pace of innovation is increasing.
Yet many mainframe customers see a chronic shortage
of qualified staff who understands these technologies,
putting at risk decades of investment in the platform.
Again, these issues are widely recognized,
widely understood, most acutely by mainframe customers
themselves.
And many are saying, we want out.
Companies have tried many different approaches
over the years to migrate off the mainframe platform
and often, never quite achieve escape velocity.
And they end up getting pulled back in.
There are three main ways customers
attempt to modernize these legacy systems on their own.
You can undertake a large manual rewrite
of all your mainframe software into the cool new language
of the week.
You can use an emulator to run your entire mainframe
environment on normal computers.
Or you can modernize in place, keeping the mainframe,
but updating the software.
We're going over these approaches
because they are all anti-patterns.
And we want to help customers avoid
these pitfalls in the future.
I've talked to customers in the middle of a manual rewrite, who
have been modernizing since Y2K.
It's expensive, risky, and it takes forever.
And if you work with developers, you
know it's difficult for them to resist the temptation
to improve things along the way.
This, of course, sets off a chain reaction
of yet more software and business process changes,
further prolonging the effort.
Meanwhile, the technology around you is changing all the time.
The idea of having a clean slate and a fresh start sounds great.
But unfortunately, experience shows
that it almost never works.
What about emulating the mainframe environment?
While you can't achieve true Cloud scale performance
with a single mainframe, pound for pound,
it's actually really good hardware.
Most of the problems lie in the ecosystem layer
and in the cost structure.
So by emulating your mainframe software
to run on different hardware, you're
really throwing away probably the only good thing
about the system and keeping all the stuff that's
actually holding you back.
You incurred many of the same risks
as in other migration approaches,
but realize few of the benefits.
What about In situ modernization.
We also see companies try to modernize in place.
They conclude that their own software is the primary problem
and needs to be updated.
At the same time, they attempted to bring
pseudo-Cloud capabilities to the mainframe.
This doesn't solve any of the problems that cost or talent
scarcity.
And it still involves a large manual effort
to update existing software.
It's a very expensive way to prolong the inevitable.
At Google, we have a different perspective.
We talk to our customers.
We feel their pain.
And they've been looking to their Cloud partners
for a way to migrate these mainframe
workloads to the Cloud.
We've built a solution called G4.
It combines Google's considerable engineering
capabilities with decades of mainframe modernization
experience.
We've developed this expertise and technology internally,
as well as through key acquisitions.
What is G4?
The G4 platform is a set of tools developed and proven
over the last 25 years that transforms your legacy
mainframe applications to run natively on Google Cloud,
by converting legacy code to m based on open standards.
With G4, we've successfully taken customers from COBOL
to containers in a matter of weeks.
What was previously too expensive, too risky,
too difficult, is now possible at Google scale.
And we believe that this is a unique offering not available
elsewhere in the market.
Let's talk about G4 for a minute and go over what it does
and how it works.
G4 consists of three major components--
the analyzer, the converter, and the dashboard.
The G4 analyzer parses your mainframe source code
to understand your business logic and program
dependencies in relationships.
The G4 converter applies conversion rules
to your mainframe code and transforms it
into modern Cloud-native Java.
The converter supports dozens of mainframe languages,
such as COBOL, PL/1 RPG, GCL, Assembly, and many others,
and can also help modernize database business logic, IMS
and VSAM.
The G4 dashboard provides performance and complexity
metrics about your software that assists in the testing
and tuning of the applications.
At a high level, our migration process
follows the tried and true methodology
that we use for migrating other mission critical workloads
to Google Cloud.
The insights from the G4 analyzer
drive the discovery and assessment phases,
which feed into the G4 converter, which modernizes
legacy mainframe code.
Proper validation, verification, and testing
ensure that the business logic operates
as expected and reduces risk.
The G4 analyzer parses and decomposes your sources
into clusters, which informs the optimal migration strategy.
G4 then converts the mainframe sources, cluster by cluster,
and produces target code in Java that is
optimized to run in the Cloud.
This cluster based strategy allows the customer
to migrate their applications in waves,
in parallel as the migration effort,
using a migration factory approach.
And I should note here, the code produced by the G4 converter
is free and clear--
no license, no lock in, and no nonsense.
Let me summarize some of the important benefits
that customers can realize.
With G4, you can reduce costs and risks, while increasing
agility and innovation.
Costs decrease when you escape the capital intensive mainframe
refresh cycle, eliminate MIPS charges,
and end reliance on undifferentiated maintenance
toil, just to keep the mainframe running.
Business risk is reduced by ending reliance
on a closed ecosystem of unsupported software
and a chronic talent shortage.
G4 increases operational efficiency, agility,
and innovation by extending the life of mature software assets,
running them on the Cloud, and leveraging existing investments
in your software.
By gaining access to modern Cloud technologies,
you can further optimize, adapt, and evolve your software
in ways that were not previously feasible.
With some of these benefits in mind,
I'd like to share with you the journey of one of our mainframe
modernization customers.
We're working with a large credit data aggregation
company.
You can think of them as a credit bureau, who
is anticipating a 5x increase in customer queries
due to recent changes in legislation.
Most of their mission critical applications
are written in COBOL and running on both
a mainframe and AS400 style systems.
They're also making use of other mainframe technologies,
like KIX, JCL, Easytrieve, and DV2.
Due to the forthcoming increase in demand,
the customer is looking to migrate
to a modern, scalable platform and to modernize
their applications to support future enhancements.
They had thousands of AS400 and mainframe programs and 12
months to make it happen.
What kinds of workloads did we migrate?
In mainframe land, there are two major categories
of workloads, online and batch.
And they have different architectural requirements.
Online programs process requests and responses in real time
and record those transactions in a database, as they happen.
So if I want to transfer $100 into my bank account,
I want that to happen now.
And that would be an online transaction.
This is also known as OLTP, or online transaction processing.
Batch programs process book data,
often to aggregate records generated throughout the day
and perform analyses.
As an example a batch process might
aggregate all trades that occur in a given trading day
and determine a bank's risk exposure.
Batch programs are scheduled using
JCL, job control language.
How did we modernize JCL batch programs?
Due to the extensibility of G4, we
can create custom conversion rules.
In this case, we modernized the customer's JCL
to run a Cloud Composer, a managed workflow orchestration
service in Google Cloud based on Apache Airflow.
These workflows trigger batch processes
running on Compute Engine container optimized
VMs inside a managed instance group.
These batch processes are Java executables running the Open
JDK runtime environment.
For online workloads, we deploy the converted mainframe
applications to Compute Engine inside a managed instance
group.
Because these workloads are intended
to be accessed by partners and customers
over the public internet, we deployed a load balancer
to direct traffic to the VMs.
And we migrated the existing DB2 database to DB2 LUW
in Compute Engine.
Depending on your access requirements,
you might instead deploy a VPN or an interconnect to your data
center for secure communication within your corporate network.
And depending on your transaction processing
requirements, we could deploy DB2 LUW directly
to Google Cloud or we can re-platform
your relational database to PostgreSQL
and deploy our Cloud SQL managed service.
OK, we've covered a pretty wide range of topics in this talk,
from computing history to Cloud economics
to mainframe deployment architectures.
So here are a few key points I'd like
to highlight before you go.
G4 is a true, end to end, mainframe migration solution
from Google.
It enables our customers to reduce costs and risks,
while increasing agility and innovation.
Proofs of concept are in high demand by our customers,
due to the potential this has to transform their business.
And importantly, Google is the only Cloud provider
with an integrated, end to end mainframe modernization
solution.
Thank you for joining me today at Google Cloud, Next On Air.
I look forward to working with you
on your mainframe modernization journey.