[MUSIC PLAYING]
GEIR SJURSETH: Hi, everybody, and thanks for joining today.
We're going to learn how Equifax simplified their microservices
implementation while supporting 2.5 billion API transactions.
But before we get to that, let me introduce myself.
My name is Geir Sjurseth.
I'm a product manager working with Google Apigee
at Google Cloud.
And I'm joined today by Neil Erickson,
Vice President of Digital Platforms at Equifax.
Something that's very important to Apigee
is this idea of a digital value chain.
It's a chain of connections between a back-end system
that's performing all the functional activities
that your organization does, all the way over to the real end
users that are consuming whatever
services and information lies in those systems.
In the middle, we have APIs developed by an API team
that provide a way for developers
to uniquely use those and use that information to develop
powerful applications.
But I want to think a minute about those back-end systems,
back-end implementations that require
some sort of extra interface in an API
and look at what that might look like in a real-world scenario.
So here we see on the left a box containing Google and Apigee's
management plane.
Connected to that here, kind of bridging those two
different services, we've got the Apigee runtime
plane connected to the customer's own VPC.
And, finally, in the right, we have their own services
that they're using Apigee to create API interfaces for--
and even microservices themselves there on the right,
probably implemented on Kubernetes running on GKE.
But believe it or not, Kubernetes
doesn't solve all of your problems.
And, actually, solving these types of complexity problems
that we see on Kubernetes becomes a microservice issue
in terms of how we're keeping track of all of these.
And that's where we start thinking about service mesh
and combining service mesh with managed APIs.
So consider this type of communication,
a service that wants to call another service inside a mesh.
And we want to make that service secure.
We want to add policy enforcement,
collect telemetry information, make it routing
and secure naming--
it's, basically, different types of policies-- quality
of service policies-- timeouts, retries, circuit breakers;
authorization policies for local lookups, third party lookups,
quotas and rate limiting; and finally,
traffic-shaping pieces-- content-based
routing, Canaries, A/B testing, and the like.
This can grow, and we need a way to make
all those routings and those different types of policies
work.
And that's where this idea of a proxy come in.
By adding this proxy as a sidecar,
we get a way to uniquely get in the middle of the communication
between service A and service B and take advantage
of all these other pieces.
And then, actually, we can reuse that same type
of a proxy for egress information
to keep track of all the connections
that are happening from inside our service cluster
to the outside world, and even at the ingress side,
where we get perimeter policy enforcement.
So with the ingress point, we can keep track of these pieces.
A mesh could span lots of different locations.
So as seen here, microservices in London, Finland, and the US,
all running on GKE, all, to some degree, interconnected.
In order to use a service mesh to get these benefits then,
we're going to connect-- so we're
going to allow the connection between these different
locations and control that flow of traffic.
We're going to secure it and automatically
secure the communication service,
the service of mutual TLS, and also
add authentication information.
We want to control how we're accessing it
and manage the traffic between these services.
And finally, we want to add lots of observability,
get different types of logging, monitoring,
and tracing information from that real runtime.
To make this easy, we've brought up
our own version of the mesh here at Google, Anthos Service
Mesh, which is going to provide the service
management as a control plane in order
to get all that type of information
you saw before-- metrics, service identity, traffic
management, all managed from this one location
but executing in your own GKE environments.
And doing this, we can move from monolithic infrastructure
to a microservices-based infrastructure
and then make that microservice-based
infrastructure tractable and manageable--
faster A/B testing, policy enforcements,
by taking advantage of all these features
that come with this idea of a service mesh approach.
But what if you want to do more?
What if you actually want to take these different mesh
services, external or otherwise, and cater them
to different types of audiences and provide
different levels of access?
To do that, we might be interested in creating
internal applications, partner applications,
the third-party apps and services,
and manage these in different ways.
To get there, we need API management
that can involve itself and connect itself directly
with that mesh level with all the things we would expect
to go into API management.
So at a runtime level, we have an enterprise gateway,
hybrid gateways, and Envoy, which
is going to provide a way for us to directly connect
to that mesh.
At the top, for the developer services,
we want to make it possible for developers to find these APIs.
We want to package them into API products
so that we can keep track of what those look like.
And connected to that, with analytics services,
we'll keep track over time for how these are being used,
which programs are having the best successes and failures--
even business metrics.
And finally, the management layer
is going to make every bit of this tractable over time
for the people that are running these platforms,
be they business side or, indeed, tech side.
Delivering this means that we end up
with an API lifecycle that starts with design,
moves on to development, integration
between the back-end and the front-end services that are
trying to consume these APIs.
We could do it securely.
We could automate deployments, publish these finished services
into a developer portal so that developers could find them,
monitor and analyze their use.
And if we get lucky, and we get to a point
where we're ready for this, we can monetize those APIs
as real products in their own right.
With Apigee being run directly on top of GCP
with that Apigee X, we get the ability
to connect to other cloud data services, Cloud CDN,
Cloud Armor for protection, Cloud IAM, if you're already
using other distributed GCP managed services,
so that you can rely on that same set of filtering
for your users, and reCAPTCHA, among other things.
There might be additional concerns
for these different types of APIs.
So product owners love this because it
means they can keep track of multichannel consumption.
They can manage these APIs to products,
monetize them, manage customer onboarding, and, indeed,
allow self-service onboarding for a lot of these APIs.
Operations folks like the API monitoring and metrics
ability they get, governing and managing access between them,
and distributed request tracing.
And finally, the API developers themselves
like the consistent security controls, the easy ability
to do logic and debugging, standardizing on API contracts,
and the way we can represent data and semantics
in a consistent way throughout all these different services.
And with that, I'm going to hand it over to Neil
to tell us a little bit about Equifax.
NEIL ERICKSON: Thanks, Geir.
Thanks for having me.
Equifax is 123-year-old company.
We have services that span the industry.
We're not just a credit bureau.
Equifax has grown through the years
through merger acquisition, regional implementations,
and rapid growth.
All of this led to a tech sprawl and technical complexity
that needed to be transformed.
Data is at the heart of what we do.
But on top of it, we have services
that process data, enhance it, filter it, create decisions,
show analytics, and look for identity verification.
We also have product services on top
of that solve common industry problems
for various types of customers.
All of this needed to be transformed.
Our cloud transformation goals are similar to a lot of other
companies'.
We wanted to reduce the complexity first.
We had a footprint of data centers
across the globe, massive sets of applications, some of them
redundant, some of them outdated, and some of them
very siloed.
All of that needed to be moved to the cloud.
And what the cloud gave us, too, is part of it
is we wanted to make sure it was a security posture and security
stance that was built in.
The cloud native zero-trust security stance
gave us that, as well as the active promise of resiliency
and the ability to focus on creating agility and scale
by the use of breaking down those monoliths that
were in the legacy.
So if you think about all those applications that are moving,
the monoliths could be redone with microservices
and creating an ability for us to now innovate and scale
with the market as needed.
So the results thus far--
we've migrated 1.5 petabytes of data to the fabric.
That's a massive lift of controls
of the regulatory concerns around how
to store data, process it, and keep it, and make
sure it's secure.
That lift alone is huge.
But then on top of that, we had to migrate a million data
contributors.
So these are external entities in how they provide data
to our exchanges to them.
We also did over 900 applications
that would rebuild globally.
So think about all those legacy apps done in a modern way
and moving towards a transformed cloud-based microservice
approach.
To support all that, we went from about zero transactions
in our API gateway all the way to 2.5 billion
monthly transactions.
So that's a massive growth that was
enabling all the traffic above.
And then we have thousands of developers and 50,000 customers
that we migrate.
So what did microservices mean to us in our transformation?
As I mentioned, it's a lot of transform, a lot of things
to migrate.
And when you talk about monoliths,
you're talking about the big box of the past,
rethinking some of those functions,
and defining the capabilities across our org
that we can then rely on consistently, regardless
of the region, regardless of the product,
and have that function in a way that
provides the values that the products need
and how we can deliver in each channel in a consistent way.
Our API approach has been coined early on by our chief architect
as APIs Everywhere.
And what he meant by that was products--
yes, we should aim--
API as a product is where we're aiming.
All the good products that we have
defined in a way that are simply defined
with consistent use of structure open API standards in a way
that they're findable, usable, and so on.
That should be at the heart of everything you do.
However, there's a massive amount of customer migration
and decades of integrations that have
been done that need to step through a transformation
and step through a number of transition states
to get to their end state.
So managing all those, also, through the use of APIs
and various techniques within the gateway itself
to help the transformation, help the migration,
and make things a little seamless.
Internal application-- so if you think
about all the things from CRMs to our core data
systems, our billing systems, the ability
to onboard customers-- all that's
powered by APIs that function inside of our company.
To the partner integrations on how we onboard all the data
and interact with those data contributors,
to the marketplaces that we want to ultimately push
those great products now we've created as APIs--
well, how do we actually further our
reach through the use of integrations themselves?
And thinking about publication syndication of APIs
out to marketplaces?
Our API approach took rethinking things from the start--
so engaging with our SLT, redefining
why APIs are important to us, what was needed to get it done,
what was needed from their part of the organization,
and getting their buy-in to make sure
that the change was going to be well adopted and well received.
Also, thinking about it from a CoE perspective and going,
how do we develop the way to start
to get people going, develop the training material,
the workshops, the onboarding sessions,
and really teaching each part of the org
through success through their first set of APIs
on how to do this, and how to start doing it
with an outside in-design principle,
and the right governance on top.
So the governance model that we chose
was to start with that CoE but then
start federating over time.
As each part of the org matures and evolves,
allow them to take the wheel where they're able to,
and compensate for that where they could.
And then adoption-- so to increase adoption,
having the right self-service internally,
as well as externally.
So internally, having the tools and the processes
well defined and the tools for that design time
and development time creation of APIs,
as well as externally for the customers
and external users of the APIs to onboard,
find use, and, ultimately, creating that developer
love that we all want.
So a couple of good examples of what
Geir was talking about earlier with the service
mesh and Apigee--
a couple of places we really found this to hold true
and really hit the point was with our internal applications.
So we've got use cases where we have
VPCs set up for a certain region,
for a certain product line.
And there's chatiness within there.
The services needed to communicate.
Rather than have those jump out and go outside the bounds
and out to Apigee external, is to have the onboard gateway
that's Apigee aware.
They treat those services like their APIs.
So we can get the control we need out of Apigee.
But at the same time, have the free flow
of information within the VPC in a more efficient manner,
as well as on the client app.
So we've had certain use cases on--
I call them sort of micro-transactions that need
to happen at a high frequency with a low latency--
so higher latency than a typical API.
There, we're trying to minimize chatiness, minimize the hops
out and back in, and get the response to the client as fast
as possible.
So, again, these use cases are a little bit more complex.
But you get the simplicity from Apigee
being able to read or monitor the way it normally
does, so you get the good view of a API,
while you get the speed of working within the GKE
environment itself.
So one of the pillars of our API program
is our developer program.
As I've mentioned, experience equals better adoption.
All of our APIs--
you can view them through our dev portal,
whether it's internal, partner, or public.
And we use-- our public runs, obviously, are
available for browse for anybody that comes and can find them.
Once you find the API that you want,
you can then register, subscribe, and start
interacting with the API filter.
We also have a provisioning layer
that allows for certain APIs to only
be granted to certain customers that
are at a different part in their transformation.
And we need to maintain a different version.
That's fine as well.
And then we also have our internal APIs--
they're in here as well.
But one cool notion that we have in the portal
is for the creation of teams.
A company can come in, register.
They can then set up their team that's
going to be developing the app.
And that app can then subscribe to certain APIs
that are in the portal.
And then from that, you can manage the promotion from dev
to test to product.
And that allows for the ability to manage endpoints and keys
in a very secure manner and very informed manner.
So the right visibility and the right governance is on top.
What did we learn along the way?
Well, one, being able to leverage the power
of a provider, leverage the power of the cloud,
leverage the power of a vendor-- a SaaS vendor like Apigee--
has given us the ability to focus our capacity
and scale on how do we grow the organization
and grow the capability inside our walls
and not have to manage as much--
do we have the right boxes set up?
Are we going to be able to scale with the increase in traffic?
So we focus on the right things--
the how do we do this better?
How do we engage our organization?
How do we engage our customers?
And we're less focused on, is the box
going to topple over if we add twice the volume?
Again, getting from 0 to 2 and 1/2 billion a month
in a couple of years' time is a massive scale difference.
And for that, it just happened.
Customer experience prioritization-- again,
if you don't have the ability for people
to adopt building and getting things to market faster,
you're not going to have success.
If you don't have the things for your customers
to adopt in an easy way, you're going
to end up having higher operational cost and slower
customer adoption.
And it's going to take your transformation times
and spread them out.
Operational simplicity-- so as you
get the set of a whole bunch of services operating globally,
and you have a whole bunch of APIs,
how do you bring some simplicity by managing those things
together and getting a single view of what's
happening and making sure your product team
as well as your ops team are informed
and reacting the way they should?
And then acknowledge it's a journey-- you're not
going to get there in one day.
You've got several things to do.
You've got to manage maturity across the organization,
look for tactics in these place to use
to get each part of the org to the next level of maturity
and move through that, as well as customer engagement.
With that, thanks, Geir, for having me today.
GEIR SJURSETH: Thanks, Neil.
And thanks, all of you, for joining us today.
If you like, you can join the community
and get answers and support from a global network of Apigee
experts by using that QR code there on the bottom left.
Explore Equifax's own APIs, browse the API products
by use case and industry with that QR code
there in the middle.
And finally, uplevel your own API skills.
Earn a skill badge by completing a Deploy and Manage API X
quest by using the QR code there on the right.
Thanks.
[MUSIC PLAYING]