AMR ABDELRAZIK: Hi, everyone, and thanks
for joining us today.
Today we're going to talk about running Anthos on bare metal
at the edge with Major League Baseball.
My name is Amr Abdelrazik.
I'm a product manager at Google Cloud as part of the Anthos
team, and I'm here with my friend, Kris Amy,
from Major League Baseball.
KRIS AMY: Hi, Amr.
Thanks for having me on today.
I run the team at MLB that covers off
all the infrastructure for our fan-facing services
which run on Anthos and the Google Cloud.
I look forward to showing you what we've got to offer.
AMR ABDELRAZIK: Awesome.
Thank you, Kris.
So the first question is, why the edge and why
are we talking about the edge?
So customers are demanding a more connected experience,
and this is happening across different sectors,
whether it is retail, connected factories, health
care, and even gaming.
What this means is enterprises need to deploy applications
in many places, whether from the left
you're looking at something at the very far edge, hundreds
of thousands of sites, very low latency, very small footprint.
And some of the use cases of that
is real time control, industrial security real time.
Or you get something like the near edge, where
you have less sites, probably less
sensitivity on the latency, and you're
looking at something like video and image analysis
and processing.
Or you go more to looking at the traditional data center
core or cloud.
And the challenge is, how do you deploy across all of these?
And this is hard, because as you're
looking to deploy across all of these applications,
you're looking at migrating applications.
The developers are deploying applications differently.
Every cloud or every site is different.
You need to deploy the application multiple times.
You can't move everything to every location,
so it is just hard to try to manage across all
of these infrastructure.
And the good news is there is actually
a perfect storm of opportunity about some
of the technologies happening in the market that
have been happening over the last couple of months.
So the first one, of course, is 5G, but also
a lot of connectivity options that are out there
that is improving connectivity, latency, and bandwidth
for those edge scenarios.
The second one is containers, when
you have a portable application form
factor that allows you to deploy across different environments
with ease.
And finally, there is the open source,
the continuous innovation with no vendor lock-in,
led by Kubernetes and many other technologies
that are out there in the markets.
So this presents a great opportunity
to use all these new innovations and leverage your existing data
and deliver your applications to where you want.
So we [? have ?] a little bit of a how can Anthos help you
with this problem.
So Anthos is our platform for application modernization.
It allows you to run on Google Cloud,
on premise, on other cloud providers, or at the edge.
And the idea is Anthos gives you managed operation, the service
management part, and the marketplace and commerce
so that you can even add more applications from third party
providers.
And Anthos gives you multiple deployment options
from cloud platform, as we discussed, vSphere, AWS.
You can even bring your own Kubernetes,
or you can deploy it on bare metal edge scenarios and Azure
that is coming soon.
So across all of these options, Anthos [? provide ?] you
the deployment flexibility to deploy application anywhere
and have the consistency of your operational workflow
and your developer workflow.
So we're going to talk a little about Anthos
on bare metal, a technical overview, which
is our newest offering that we announced recently.
So the idea for Anthos on bare metal
is you can run Anthos on a customer-provided operating
system.
In this scenario, you can install Anthos
where the customer deploys and manages the OS lifecycle.
You have pre-flight checks to validate the minimum system
requirements, and then you have idempotent and declarative
installer for all Anthos components.
[? While ?] you can run it from a compute capacity,
you can deploy this on a physical
or a virtual infrastructure.
Now we expect most of our customers
to run this on physical server, but running
on your choice of [INAUDIBLE] infrastructure
is also possible.
We intend to support RHEL, CentOS, and Ubuntu.
And from a networking standpoint,
N3 connectivity between the nodes is required,
and we need L2 between the load balancing nodes,
but Google provides an overlay networking L4 and L7 node
balancing.
From a storage, you can integrate with your storage
infrastructure using CSI.
Upgrade will be in place, and from an observability
standpoint, of course we have out of the box
Stackdriver [INAUDIBLE] Cloud Monitoring metrics and logs.
Or you can integrate with the customer-provided observability
if you want.
We're also considering VM lifecycle options
with technologies like KubeVirt and many others.
So this provides you a very flexible
stack where you can deploy on your existing infrastructure
and easily run application using Anthos.
So in terms of managing Anthos at the edge,
some of the technologies and the capabilities that we have
makes it very easy to do so.
So we're going to cover some of those.
So the first one is the standardized architecture.
Again, you have the flexibility to deploy on VMware,
deploy on your favorite operating system.
So this gives you tremendous flexibility
to deploy where you are and not have to retrofit your existing
infrastructure.
In fact, you can leverage your existing infrastructure
to meet your current needs, and you can even
modernize it in place without impacting the apps.
So that's the first piece of the application modernization
managing [? of ?] [? it. ?] The second is managing the entire
fleet, and one of the challenges that I've seen a lot
of customers is they have thousands of stores,
thousands of locations.
So managing across all of these locations is very hard,
and having a cloud-based monitoring solution
and management solution helps you there.
So one of the technologies is the single pane of glass
to have for your clusters and workloads.
You can manage the cluster from a single cloud-based web
console.
You have visibility for your entire fleet,
no matter where they are.
And you can deploy workflows from a private registry
or from a GCP marketplace, all of this from a console
or a centralized API through Google Cloud.
So this gives you great flexibility and a single point
to manage and deploy all your cluster.
The second part is centralized logging and monitoring.
As you look across all of these locations,
you need to understand what's up, what's not.
You need to diagnose.
Sending a technician can sometimes
be very costly and very time consuming,
and have an impact to the business
if you have a store that is down.
Centralized logging and monitoring
helps you with that by aligning all of the data
and pushing it to Stackdriver, or now Cloud Monitoring.
And then you can see what's happening,
error rates, performance.
You can even manage the lifecycle of those locations
and define SLO and monitoring for your SRE codes and signals.
So that's from operations, and then that gives you
the fleet-wide policy management, again through--
do this from a kubectl.
You can also use GitOps.
So from a programmatic SRE kind of standpoint,
you can use DevOps technologies.
You can have your single team deploy,
for example, a canonical version of the app, one place,
and it gets replicated across all of your stores
in a matter of seconds.
So that also gives you a lot of flexibility
of how to deploy apps across the fleet.
So we want to talk about edge deployment models here.
And one of the interesting innovations
that we are introducing to the market
as Google is, as a customer, you don't have to manage or deploy
all the apps.
We give you different options to do so.
So the first part worth mentioning
is Google's global network.
And this is something that is very unique to Google, not just
by our data centers but our connectivity
to region, PoPs, and networks that you've
used over the years for Search, for YouTube
for Stadia and gaming.
So these are a combination of CDN edge point presence,
dedicated interconnect, and even cloud regions that gives you
a lot of flexibility on that.
So from that, we have 24 regions.
We have 144 edge PoPs and thousands
of edge nodes in telecom networks.
But that's the part that we are starting
to have innovation for it.
As you integrate with existing telecom partners,
that gives you a lot of options to expand our network even
further in this partnership and gives you even closer points
of presence across the globe.
So this gives us a flexible operation model for the edge.
So we have three options that will
make your life a lot easier as a customer to deploy the edge.
The first one is a Google-managed edge.
In this case, you are leveraging Google's capability,
Google's infrastructure, for example like edge caching
and service nodes and using edge point of presence
on Google Cloud, either core regions and zones or edge
regions and zones.
So that's the first option.
The second option is telco edge, leveraging our existing
partnership with the telcos and using
their small central office presence,
a large central office presence to deploy this, for example.
So you don't even have to have it on the store.
You can have using a combination of 5G
and then have your equipment, or actually the telco's equipment
running your application.
This gives you the ability to deploy, for example,
next to your store.
So you don't have to have the presence in the store itself,
but actually have something that is
very close and very connected.
And finally, of course, the customer
edge, the classical customer edge scenario,
where you are deploying on your existing branch
office or your existing retail location.
And that gives you the traditional presence
that you have, but also gives you another option.
So between the three options, that
gives you a lot of flexibility on designing
your own infrastructure to meet your needs
and the appropriate operational model for your business.
For a sample edge architecture and how the edge is evolving,
this is, for example, a real time inventory management
and analytics architecture.
So if you build this architecture just
on a cloud-only kind of set up, this
is how it would look like, where you
have the point of sale inventory and RFID systems in the store,
but then you have a lot of capabilities
in a cloud provider like Google Cloud Platform,
using technologies like Cloud Pub/Sub, aggregation analytics,
and video APIs.
But we also have in this, what Anthos
gives you is a new architecture where you can move in some
of those capabilities to in-store,
again, to make it closer to where you are,
so that you can leverage your platform of your choice
and the services that you need, but still
have the latency and the sensitivity.
So again, flexibility in the architecture
of how you build your applications
gives you a lot of options on how
you want to run your business.
So in terms of innovation, our goal
is to help you with our industry-specific solutions,
from retail, health care, financial services, media
and telco, manufacturer, and public sectors.
Across all of these, there are many solutions
that are built out there, best practices and expertise
within Google Cloud that we can leverage and help you
to build your own industry-specific solution.
So next, I would like to introduce
a use case of using Anthos at the edge with Major League
Baseball.
KRIS AMY: Thanks, Amr.
Thanks for having me here.
So I thought, what better way to start
this whole section of the presentation off than,
let's go through what an actual end user experience is like.
So what we're seeing here is a product that we call Game Day.
You go to MLB.com.
You click on a game.
You can see a sort of virtual experience in a game here.
And what we're seeing is play by play data.
We're seeing pitches and how the pitches were
thrown, what the velocity was, where
they were in the strike zone.
Then we get into what actual plays happened.
Did a runner steal?
Was there a pick-off attempt?
Was there a home run hit?
And even that, we're loading videos of key parts of the game
straight into the feed.
And so how does this all come together?
We start off with our new stack [? cos ?] tracking system
that we have for 2020.
This is a completely new system that we've
developed and deployed.
It uses machine vision with a whole stack
of cameras that pick up velocity, spin
rate of the ball, where players are, what their poses are,
and what's happening in the game.
So what we're seeing here is a pitcher
from the New York Yankees.
This is a video that we took last year of them actually
throwing.
You can see how the ball--
we pick up the trajectory.
We can put it back in time to work out where it came from
and where it's going to be going through.
So how does this all work?
Well, as you know in baseball, it all
starts with a pitcher throwing a pitch.
So we kick it off.
We have an on-field play that happens.
There's someone in the stadium, all remote, who
clicks for the start of the play,
and they complete the play once it's finished.
Our tracking system is going to absorb all the data and all
the events that are happening throughout that play,
we aggregate it, and we process it in stadium on Anthos.
So we collect all of that data, we process it,
we set up a play, and then we ship it up to Google Cloud,
or potentially in stadium if we have other subscribers that
need that information for low-latency reasons in stadium.
So where do we come from?
What do we do?
So in 2019, we had an aging hardware stack in stadium.
You can see that on the right.
That's what the end result looks like.
We had this aging hardware.
We were bringing a new tracking solution coming in,
and we needed a way to simplify, modernize, and bring
consistency to our on-premise or in-stadium environment
to what we run in the cloud.
And we had to have something that
would run there, be stable, and enable
the throughput and the latency requirements
that we have in stadium.
So what does our environment look like?
Last year we virtually had one virtual machine
for every application we ran in the stadium.
It had some local storage attached to it.
We packaged our apps with RMPs.
We had no real automatic failover.
We had to run two copies of everything,
because if we lost one, we had no way
to automatically stand it up and run it
by a second location or anything else.
And if we had a burst in the stadium where
we had to process a whole lot of data
and potentially we were going to resend a whole lot of data
from a game that happened in the past,
and we want to get it processed really quickly,
we had no way to flexibly to scale up,
scale down as we needed.
So we come into 2020.
What do we do?
We took Anthos on prem.
We're running on top of VMware.
We made the decision that--
we saw Anthos as this standardization for containers
for all of our applications, regardless
of where we ran them, whether that's in Google Cloud,
whether that's on prem, or even in our stadiums.
We had this key requirement for automatic failover
for our processing of all worker nodes,
and we needed out applications to be
able to horizontally scale in the stadium,
just like they would scale if we're
running on GKE in the cloud.
So our architecture, it's probably
a little bit different from your standard Anthos
on-prem architecture.
We have our admin workstation that
runs inside GCP in the cloud.
And then for every ballpark, we've got two here displayed.
We've got the Rockies and the Marlins.
We don't have shared storage in the park.
We basically have two processing nodes that we run.
They run VMware.
And then on top of that, they have local storage.
We run the Seesaw load balancer setup for each cluster.
So we had each node.
It's its own cluster.
It has its own admin cluster, the control
[? planes, ?] et cetera.
And then inside that actual physical hardware machine,
we had the various worker nodes that we need.
And in our case, we run three different worker nodes.
So what's our end user interaction?
We do all this processing in stadium on Anthos.
Where does the data go?
We'll ship it to in-stadium experiences.
So that could be up on the scoreboard you'll see.
You know you can see that at the score change,
or you see a pitch speed, or what type of pitch it was.
We offload it to our broadcast partners watching on TV.
And you see the pitch trajectory or [? where ?] the home run
was hit, et cetera.
We also then take that data, and we ship it up to Google Cloud,
where you get experience from our digital properties
and products.
That's what we started this whole session off with
was Game Day, which is one of those digital properties
or products.
We also do advanced data analytics on all this,
and we do AI and ML to work out what's
going to be the new metric that we're going to see come out
of baseball in 2020 or 2021?
So where do we go to from here?
I covered off just before what we do right now on the web.
What we got loaded up here is a rendering
of an actual play that occurred virtually.
It's concepts around, what can we do with this data
that we haven't ever thought of?
And this is where we see Anthos is a key for our go forward
with all of our data that we're shipping from the park.
So with that, I'd like to throw it back to Amr.
Really great to be here today, and really
excited to see what Anthos can offer.
AMR ABDELRAZIK: Thank you very much, Kris.
That was a very cool use case.
And as you have seen, it demonstrated
the power of Anthos.
MLB team had a virtualized infrastructure at the edge.
They deploy it.
It's the same infrastructure that they deploy on the cloud,
and had the same infrastructure as they migrate to bare metal.
So our goal with Anthos is to bring
the same level of flexibility and the power of Google Cloud
to the edge with an open application
platform, flexible deployment option, and a strong ecosystem.
So I encourage you all to try Anthos on GCP.
You can see this link here.
The link has a lot of tutorials, a lot
to demonstrate and try a lot of the capabilities of Anthos.
And at the end, I just want to thank you all
for giving us the time today.
We know it's a crazy world out there, so we really appreciate
you taking the time to learn about our technology
and our product, and we look forward to partner and work
with.
You.
Thank you.