STEPHANIE WONG: Hey, everyone.
It's Stephanie Wong, Cloud Developer Advocate.
And today I have, again, Google fellow Eric Brewer.
Here, we have him doing a series of videos.
We hope that you have enjoyed them so far.
But Eric, we are both so excited for this one,
because we are gathering our questions from the community.
ERIC BREWER: I am looking forward to this.
It is true.
STEPHANIE WONG: All right.
So we have both put out a prompt for questions.
And this is meant for anything that you've
been curious about around Eric's work
over the last decade, any advice that you've
had for our next generation of developers,
especially in the Kubernetes space.
So first off, the first question that we've gathered
is, can we make use of Kubernetes
in the edge, namely the Raspberry API devices,
where security can be a big challenge?
ERIC BREWER: Well, people are definitely using Kubernetes
at the edge, mostly in the telco space and the retail space.
Certainly, some well-known large customers
actually run Kubernetes clusters in each of their big stores.
So it's definitely in use in the edge today.
It also runs on Raspberry Pi, so that it's not, per se,
new either, although that is a more constrained way
to run, for sure.
The implicit question, though, that it's less secure,
I would say is neither true nor false.
I would say Kubernetes has certainly an option
to be quite secure, as secure as other things based
on, say, traditional VMs.
However, it really comes down to the whole stack.
So what is the security of your hardware, for example?
Do you have any root of trust in that hardware?
Google servers that we put in our data centers
actually have a hidden key deep inside so
that we actually know we're running on a real server.
We know that the BIOS is trusted.
We know that the OS is trusted.
So we build up a trusted stack and run on that.
That's historically harder to do at the edge,
but it's still a good goal.
STEPHANIE WONG: Right.
Increasingly important as well, especially given the work
that you are doing around bringing security
to this Kubernetes and open-source era.
Now, what about data?
So we have another question about what Kubernetes
would look like in the--
I'm assuming data analytics space.
Currently, data applications are relatively Cloud-specific.
ERIC BREWER: Certainly, Kubernetes
started with less focus on data and more focus
on services, especially stateless services.
Those are the easiest to do for lots of reasons.
And that goes, again, back to the '90s.
That's a basic principle.
But everyone is building data services
on communities now of many flavors,
and it is certainly possible now to do a good job of that.
But I think the question sounds like it's more about,
how do we have the same kind of revolution for data
that containers brought to computing or services brought
to computing?
And that is a great question, and it's not easily answered.
But I think the service is a good framing for that,
meaning that when I talk about data,
it's not just the actual data.
It's probably, what are the methods,
to use the object-oriented paradigm,
or the APIs around that data?
Because if I have an API view in my data, then
I also start to talk about policy,
who can read it, who can write it,
access control kinds of things.
Maybe I can force other policies like data locality.
This data needs to stay in Europe, for example.
So I do think we need a bit better packaging
of the data itself and the wrapper around it.
And I would say this group is exploring that.
But I would say that's still to be.
STEPHANIE WONG: And this is related,
but I think there's also an increasing need for more
processing power to do things like machine learning, data
analytics, high-performance computing.
So what is the future for co-processors in the Kubernetes
space, like using GPUs, TPUs, et cetera?
ERIC BREWER: Co-processors in general
are an important part of any computing future.
We're at the end of Moore's law, in the sense
that general-purpose computing is not getting
as fast as it used to per year.
The rate of change is slower.
It's just too bad for all of us.
One of the few ways you can make up for that
is to have more domain-specific hardware.
That's what a TPU is, for TensorFlow.
That's what a GPU is, both for graphics, and it's used for AI.
So accelerators are here to stay.
And in fact, you can use both TPUs and GPUs from Kubernetes.
There's nothing, per se, wrong with that.
I would say there's a new offering of Kubernetes on GKE
where you can actually subdivide a GPU into smaller pieces,
so that it's actually easier to use a small amount particularly
for inference, or to use a large amount if you
want to do training.
But absolutely, that is part of the core future of Kubernetes.
STEPHANIE WONG: Yeah.
And it's been incredible to see the extension and the usage
of Kubernetes in the machine-learning space,
especially with open-source platforms like Qflow
and what we've built into Vertex AI.
So it's really exciting, and I'm looking forward
to seeing where we start to implement those things.
Now, this question is a common question that I think we get.
But talking about on-premise private clouds
versus public clouds, to you, what
is the right balance between open public cloud and private,
closed, sovereign clouds for companies?
ERIC BREWER: That's a very tricky question,
which many countries are worried about.
So the short answer is, you'd be better off
with an open public cloud pretty much
all the time if you can use one, because it will have better
cost efficiency, will have a higher rate of innovation.
It can do more things over time.
However, that means you must not only trust your cloud provider,
but you also have to trust the government that
runs the country which your cloud provider is based,
which for most of us is the US.
So if you're a country that is worried about the US government
you may decide, that at least some of your workloads--
that's too risky, and you really want them
running in your own country.
That's where the word "sovereign"
comes from in these contexts.
Now, the good news is, something that's
based on open source like Kubernetes
is amenable to running well in private cloud.
That's a big part of Anthos, which
is something I've worked on, also,
for both hybrid and multi-cloud.
So you'll see us talking about sovereign
in terms of our general open cloud extension,
because at least that means you can use Kubernetes on GKE.
And if for some reason you need to exit, for whatever reason
you can run Kubernetes on-prem, and at least your workloads
will be movable.
Now, is it trivial to do that no.
But it doesn't have to be trivial.
It just has to be possible.
STEPHANIE WONG: Absolutely.
It's a tough space.
But it's going to continue to evolve over
time as our geopolitical climate changes.
So it's a lot to think about now.
Now, many, many great tech, including Kubernetes
and BigQuery, as you know, came from internal Google technology
that we've decided to externalize.
So I think the community is curious,
but what is the next big thing that we are hoping to
or we think we might externalize?
ERIC BREWER: Well, I think it just happened,
but people didn't realize it, which
is Google has great internal solutions for supply chain
security.
We've written papers on it.
VCID is the internal name.
I don't know what it stands for, but basically, it's
a set of invariants about how our software is
built, such that we can prove things
about it before it operates.
For example, we can prove internally
that every piece of code is in our repo
and that multiple people have looked at that code
to make sure that it's safe.
And those are strong safeties to be able to make,
and we can make them internally.
Now, to externalize that is kind of like externalizing Bigtable.
We didn't actually release the actual Bigtable code.
If we had, no one could have used it,
because it had a lot of dependencies on internal Google
stuff.
So we wrote a paper.
People wrote versions of it externally,
leading to HSPACE and other things.
That's one model.
The equivalent here is SLSA, which is now part of OpenSSF,
where this is a framework for how
to think about supply chain.
But the good news is, it's based on what we actually
have been doing internally for, I think, at least 10 years.
And we already know where it's in production.
So like Bigtable, it's proven in production.
We actually externalize it with the community.
Because again, we need to have buy-in on how it works.
It needs to be done in an appropriate way
for open source, which is not that easy.
Hence, need some discussion.
That process is going on now.
People absolutely are welcome to contribute.
It'll also be a big part of the executive order
as we move towards secure supply chains
in general for the nation.
STEPHANIE WONG: Exactly.
It can't be done in a vacuum.
And we are inviting the community
to help us bring these things to the broader
industry as a whole.
So that is a great note to end on, Eric.
I know that you have shared your time with us over the span
of this video series.
So I just want to thank you so much for sharing your knowledge
and your experience.
ERIC BREWER: My pleasure.
And great to be involved in this way.
Thank you so much.
STEPHANIE WONG: For everybody else,
we hope that you enjoyed this video series.
Let us know if you want more like this.
And if you do have thoughts, comments, questions, concerns,
jokes, check us out on social.
Reach out to us on Twitter.
We'll include our handles here.
Thank you so much, everyone.
[MUSIC PLAYING]