EP214 Reconciling the Impossible: Engineering Cloud Systems for Diverging Regulations

Security running.

Hi there. Welcome to the Cloud Security Podcast by Google. Thanks for joining us today. Your hosts here are myself, Timothy Peacock, the Senior PM for Risk Analytics in Google SecOps, and Anton Chuvakin, a reformed analyst and senior staff in Google Cloud's Office of the CISO. You can find and subscribe to this podcast wherever you get your podcasts, as well as on our website, cloud.google.com/podcasts. If you enjoy our content and want it delivered to you piping hot every Monday, please do hit that subscribe button. You can follow the show, argue with us, and the rest of our Cloud Security Podcast listeners on the Google Cloud Security Community page. Anton, we are talking about compliance, regionalization, regulation, Swiss customers, GovClouds, and it was interesting.

Yes, but I think you started on from picking on the dry things, but—

But it's interesting today.

Yes, because ultimately imagine that you're building a single system, and it's definitely one single system. It doesn't matter what it does. I mean, in this case, it's cloud. But 2 corners of that system have absolutely conflicting requirements. Somebody says your system must do X, and somebody else says your system must do anything but X, anything but X. But it's a single system, and you're in charge of building it. So, to me, this is the incredible—

I would find something else to do with my life.

Exactly. That's the first thought that comes to my mind.

What the hell?

Build your own system if you want to. if you want for it to never do X. And because my system does X and I like it, so I'm gonna do it and you do your own.

But that's not what we do here.

Exactly. And I think we managed to solve some of the really hard problems that feel even logically hard, not only technically hard.

Like laws of physics hard questions here, listeners. And today's guest is the leader driving that innovation forward from the product management side of the house. And so without any further ado, Let's welcome today's guest. Today we're joined by Archana. Archana, you are our product lead for regulated and trusted cloud. We're delighted to finally have you on the show. As I understand it, you're responsible for building the technical systems that allow us and our customers to comply with laws that are often mutually contradictory. This seems like you are faced with a technical, regulatory, legal physics impossibility in many cases. So how do you do that, and how do you help our customers be confident about that?

Tim, thank you so much for having me. Let me first take a moment to introduce myself. Really nice to meet you all. I'm Archana Ramamoorthi, and I lead product for regulated and trusted cloud at Google Cloud. Now, you can think of it as architecting confidence for customers. So if you think of today's world, especially in regulated industries, Cloud isn't just about tech, right? It's more about trust at this point. And my team and I are essentially building that trust into GCP, sort of ensuring that it's the most secure and most compliant cloud that folks can use globally. Now, coming back to your question, it does sound impossible, right?

Right.

It's almost like circling, like squaring circles in code. But here's the thing. When you strip away the legal jargon, regulations are fundamentally about people, right? They're about protecting individuals, their data, their assets, ensuring that progress doesn't come at the cost of control. So in the digital realm, this kind of translates to universal principles, things like data privacy, robust security, and granular access control. So, suddenly, when you think of it that way, the contradictory laws become facets of the same, like, gem, if you will.

Hmm.

So, our job is basically to architect systems that are grounded in those core principles, basically creating a flexible platform. So, you can think of it like building with Legos, having fundamental blocks that can be assembled to meet these diverse regulatory requirements that you see around the world.

Tim is, yeah, well, this because we are on video, Tim is looking very thoughtful.

I'm feeling very thoughtful. I'm trying to process that one. But Anton, while I struggle through all of that, why don't you ask our first follow-up? 'Cause I like that question a lot.

I think that this also brought up this whole debate about, well, not debate as such, but like regionalization versus globalization, because I don't want to immediately ask you a hard question about what about the conflict in regs? But how do we approach the fact that we started with one big global planet-scale supercomputer, and now we are kind of trying to address things that may not align? Let's not call them contradictory quite yet. So, what is our approach to this? Again, it sounds one of those physically impossible things.

Yeah, I mean, look, people come to us still for the same things that they came to us many years ago, right? The atomic clock precision, for example, that Google's global infrastructure provides is still our superpower. We don't wanna get away from that superpower in any case. And the planet-scale compute is precisely what these customers come to us for, irrespective of what workloads they bring onto the cloud. So our evolution isn't about abandoning any of that. It's basically how do you augment it? And so the question has become, How do we retain that global muscle while also providing the localization and the jurisdictional controls that these regulations often demand? And this is what is becoming the front and center of the conversation, right? So it's the architectural evolution or the layering approach that becomes important. So we're platformizing our services, we're ensuring that they can operate as global subsystems, but with the ability to sort of instantiate jurisdictionalized versions as required. So you can think of it as global orchestration with local instantiation in some sense. So it's a full-stack approach from the deepest infrastructure layers, kind of all the way up to the user-facing capabilities and services, ensuring that every new GCP service sort of inherits these principles of the global scale with the local control baked in. And this means we're working with several teams across the board in ensuring that they can meet these requirements. But let's even step back a little bit, right? Like, a lot of this comes with customer empathy. We've talked about the regulations, we've talked about how this seems impossible to build, but the fundamentals of this is we have built Google Cloud from day one as a global platform. Now we're building customer confidence, and we're not just saying trust us, We're building that deep empathy and understanding this regulatory landscape, the specific challenges that customers are trying to meet, understanding what concrete solutions will make them feel comfortable. And this takes years. So for example, we've worked with the European Union since 2019. And in that process of working with them since 2019, we engaged with intent with a lot of policymakers. And ultimately we started asking them the question of why do they care? And we were able to sort of shift the conversation sometimes from data residency, which is often the red herring, to true data access controls, because ultimately control is the real lever of sovereignty, right? And that's where we wanna make sure that we're focusing on our engineering side as well as helping customers focus on the regulatory and product side.

So I still have maybe not doubts, but it's in some cases I'm listening to you and it makes sense, but when I think, Well, wait a second. In region A, they want X. In region B, they want Y. We have the globally consistent system that somehow addresses both X and Y. I don't understand it. Like, can you maybe explain how we make local compliance yet global consistency of the system? This just sounds magical. Sorry, magic wand.

You have to explain your tricks to Anton.

just a Google challenge, right? Like, everybody faces this challenge. Our competitors face this challenge.

Yes.

And every player is thinking about their approach in a very different way, right? And for example, our competitors do GovClouds. We have other players that have said, we're setting the stage. Isolation is the only way in which we can make things possible. We're going to have a GovCloud instance that actually meets these requirements. And we said, we're gonna do this in a very different way. And Anton, I think going back to your question, France has very different regulations, for instance, compared to the US and same with other countries. So we don't wanna have the low bar of meeting the regulations in some places. We wanna set ourselves for the highest bar because if we can meet that highest bar, we're actually gonna meet the regulations in all of these different markets. So our strategy is more about modularity and customization. So we're building with fundamental reusable components, and what we do with these fundamental reusable components is we create these individual Lego blocks. So I'll give you an example. When we're talking about data residency, we're saying, hey, the way we would build and architect data residency is we would classify data into various different types. We have different subsets of data that a customer might bring to the table. It could be core customer content, it could be billing data, it could be metadata. And then for each of these functionalities, let's actually figure out what our strategy is going to be for data at rest, data in use, and data in transit. We'll build a platformized mechanism underneath the covers and set that common ground. And then every service in GCP just needs to start using those components. And when they use those components, everything underneath becomes, you know, abstract for them. They don't need to worry about meeting those individual capabilities themselves. All they're doing is making sure that they're going into a localized version of the platform, which then takes care of how the data gets stored behind the scenes in localized instances of our, you know, ultimate core layer. So the way we dissect the problem is different. And then we layer on top of it an approach where we say, look, ultimately, if the core goal is to ensure that a person, when they put their data or their content inside Google Cloud, has complete access and control over it, then let's layer on capabilities like encryption, for instance, and then add to encryption the layer which is customers being able to manage their own encryption keys. So ultimately, it doesn't matter where the data resides. The issue is who has access to that data. We solve that problem by layering on these individual controls. Then depending on the country we go to, we can then pick out these Lego blocks and stitch them together. So for a country where they say, You know, I don't even trust you, Google. I wanna basically ensure that there is not just encryption at rest, I want encryption in use and in transit. We would layer on, let's say, confidential compute and give them the ability to add that along with the rest of the other capabilities, right? So it's basically the ability for us to say, look, we wanna give you the best of everything. Public cloud is the way to get that because we're gonna keep up with the innovation. We're gonna provide you with all the capabilities in public cloud. How can we get you the best of public cloud while layering on the right security, compliance, and privacy capabilities to give you the guarantees that you're looking for from a sovereignty standpoint?

So, this, at this point, it makes sense, actually. I think the last explanation finally clicked for me, because kind of like GovCloud is like a cloud in somebody's basement, which is separate, and the basement probably isn't very floodable. But separatedness make it kind of less cloud, right? It's not like real cloud. It gives you like this little leftover, like, it's kind of very Gov, but it's not very cloud, right?

Yeah. And I mean, think about it, right? You're getting GPUs today, TPUs today. We're talking about AI workloads. The minute you section off a set of hardware and say that's for a very specific use case, that is obviously not gonna get the latest and greatest. Everything is gonna come to cloud. And then after that, things get added on to other areas, right? So even when, for example, we're trying to meet French regulations, where we're building a separate universe for France, for instance, with our Trusted Partner Cloud program, we're making sure that anytime we make updates to public cloud, when an instance of update gets pushed out to public cloud, it also gets pushed out to this new environment. So we're being very conscious about how we design our products and our capabilities and ultimately rooted down in the power of choice. Which is that customers should be able to pick and choose what meets their need. Google shouldn't be the one that's dictating what their needs should be. We can influence, but not push.

Hmm. I also love that answer. One, because you talked about confidential compute, and that has such a special place in our podcasty hearts. But 2, on the GovCloud front, how to say this? I've always thought that GovClouds look like the most tempting targets on earth. And it's always struck me as very odd that as a cloud provider, you're like, over here, these are all the interesting workloads. And the government customers have always said, oh yes, I will step into the thing that says target me here. I've never understood that. So I want to ask a very PM question here.

Oh.

Which is engineering takes a long time. How do you as a PM and as a leader of a PM org have a world where you've got enough agility in your definition and engineering design to give both robust foundations And also keep up with changing and in many cases diverging regulatory paths. That's like another magic circle you've squared. How did you do that?

Yeah, actually, I touched upon it a little bit with my previous answer. You're absolutely right. Agility is very important in this space. In fact, it's interesting because I follow elections around the world. I'm waiting for the results of the German election next. There's Japan that we're going to have to look and see how things fall. With each of these changing regulations, there is a change in technology perspective from that country, right? And with this regulatory landscape being a moving target that is influenced by geopolitics, there is cascading tech implications on GCP and every other provider, right? So our strategy is kind of twofold. Number one, it's foresight, predicting or understanding how governments might evolve their strategy. We've also seen this pattern over and over in different countries, right? So it's not like, you know, something super different is going to come up. It's just their stance might change from where they are today to where they are tomorrow. And this is where what I said before comes into play. The way we build our products is using these Lego blocks. So let's say there is, you know, you built a house, you need an extra tower. It's not very difficult to then add on that new Lego block. So what is more important from a strategy perspective is How do you build these individual Lego blocks and how many of these Lego blocks do you need to meet the requirements of some of the highest standards and customers that you're dealing with, right? So that's the problem that my team and I think about day in and day out. Like, what are the top blocks we need to build? Is it data residency? Is it access transparency into everything we're doing? Is it exfiltration controls that we're thinking about from a GCP standpoint? Are we thinking about blocks like confidential compute? And even beyond confidential compute, are there specific use cases that'll actually require special instances that are useful for certain regulatory requirements. So, those are the kind of things that are super critical and ensuring that we're forward-looking in terms of building our roadmap for these Lego blocks, because putting them into solutions is a much easier problem, if you will.

Hmm.

Now, the second thing that is interesting is we kind of operate in a centralized-decentralized model. And what I mean by that is when we're tracking regulations or we're designing the platform capabilities into our foundations, we're doing that centrally. So that each team is not going and interpreting the regulation a certain way and building capabilities. And then what we do is we deploy horizontal programs to ensure that every GCP service inherits these controls and capabilities. So ideally, the plan is if all of these service teams build out their capabilities utilizing these framework components that we provide, changes will come to them for free. And of course, running horizontal programs is never an easy thing, and it's never a fun thing.

Mm-hmm.

Because individual teams have their own priorities and things that they should focus on, but that's a thing for a different day.

We could do at least a half hour about running horizontals.

Yes.

But it is also interesting that there is an incredible amount of really top-shelf, and by this, I mean really top-shelf engineering that goes into this.

Yeah.

This isn't just— so people associate sometimes compliance and regulations with auditors in little sad hats and checking boxes, but this is a lot of Really hardcore engineering is here. And that to me is the impressive part.

Thousands of engineers, right? We're not talking about like a small team of engineers. We're talking about thousands of engineers, policymakers, folks from our CISO office. There are several people and folks around the world that are working with us to ensure that we're building the right set of capabilities and we're baking it right into the foundation. So not treating compliance as a checkbox, because that's an easy thing to do. But truly saying, how do we up the bar for what we can deliver on public cloud so that there's no compromise? And folks really don't have to think about checking the box, but actually saying, look, if I land on GCP, I'm on the safest cloud, I'm on the most trusted cloud. I have the evidence and observability that's required for me to prove to my auditors and my regulators that my workloads are safe. And that's the most important thing.

So what are some of the hardest challenges that you faced working in the trusted cloud space? And I think we meant to ask it very broadly. Like, you can pick people challenges, you can pick code challenges, you can pick leadership. This is meant to be about you and not just about the topic.

Yeah, I think there are a few things, right, we can talk about. I'll probably mention 3. The first one is obviously, like, the fundamental tension between simplicity and specialization, if you will. So, there are simpler paths that our competitors sometimes have taken, just put this in a corner, treat it differently, do it differently. We made a conscious choice to go against that grain, right? So we believe that the same cloud should be able to meet the requirements of all customers. But this means we are also going against what policymakers and technologists are familiar with, because there's a familiarity bias and everybody's familiar with a GovCloud. So there's obviously the question of, hey, how are you able to achieve the same thing that we were told we need a GovCloud for? So Being able to work with people to make them understand the power of the solution, I think, is one of the first challenges and also an interesting problem.

Hmm.

The second one is, you know, the major challenge, which is navigating the fear of the new, which everybody has. As soon as AI came in, that's a very prime example. The US slapped on regulations, the European Union worked on regulations. Everybody's thinking about regulations because people are worried, right? Every time a new technology comes in, along with it comes in a lot of compliance for it or security capabilities for it and anxieties around it. So the ability for us to prove that our solutions can scale even with newer technology that comes up and it can meet the bar that regulators and customers are looking for, irrespective of whether it's data or AI or any other technology innovation that happens. And then I think the third one is always the challenge of we're a very large company. We have really large teams. Each of our service owners are working on their own silos and their own products, being able to corral the troops and ensuring that everybody's on the same page with respect to what their product needs to do in order to meet the demands of regulated customers. And these days, a lot of industries are regulated. It's not just public sector, right? We're talking about healthcare, we're talking about manufacturing, in some places retail, financial services. So when you start dissecting it by verticals, we are actually talking about a major subsegment of the market that you would go after when you go into any geolocation. I think all of that comes into play, and I would probably say those are the 3 major things I can think of.

Well, if those are the only 3 problems you have, you must have a very easy job.

The way I explained those problems should say how big, you know, a problem those 3 are.

It's a massive set of challenges, and every time I turn around, I feel like there's another set of brilliant new PMs working under you. So it's been really fun watching that. I want to ask about you a little bit and about your leadership journey. There's all kinds of interesting biases and stereotypes that people face. Do you want to talk about a little bit for our listeners your approach to leadership, how you've overcome those challenges, what you've seen, and what advice you have for the world?

Yeah, I mean, I think as a product leader, I would say one of the most important things to cultivate is empathy. In my job, I actually work with folks around the world, right? I have calls with the European union, with customers in Europe, with customers in Japan, in India, in Australia, every part of the world that basically has regulations, which is all the countries in the world.

All the countries.

Pretty much every country has some level of regulations, right?

Yeah.

So, any place where GCP decides they're gonna have their business is a place where I'm actually engaged in conversations. And I think the core aspect of my job that I really enjoy, which is also sort of Something that I bring from my personal life, I would say, is I enjoy travel. I enjoy cultures and understanding people. And I think that's a core facet that's required to make any good product win in any market. So, product 101, I would say, know your customer, understand your customer, empathize with your customer, and understand why they're asking you what they're asking you for. And then I would say, cultivate conviction, have very strong opinions that are backed by data. And don't be afraid to sort of voice those opinions in the room and bringing your own authentic self to the table and making sure that those strong opinions are loosely held is sort of something that I really live by, right? So, I would say that's probably one of the most important things from a product standpoint. And second is the team is everything. Like, I love building incredible teams, diverse teams, and actively working on pulling folks up. And I think mentorship and sponsorship are not optional extras, and they're core responsibilities within the job. And I truly believe that that's something that helps not only in helping people with their trajectories, but also in helping them build the right products for customers. So, I would say those are the things that I would probably deem as important as a good leader.

Let me sort of go a little bit off topic, a tiny bit, and kind of come back to a question that we started with, namely that with regulatory requirements. And it's been kind of nagging on my mind as you were describing those amazing things you've done and your teams have done. And it is the question of, like, directly conflicting requirements. If I want my cloud to do X and this other person wants his cloud to never ever do X, anything but X, how would we handle it? And I can't think of an example. And maybe if I can find an example, it may be too politically sensitive. So, let me Just pick some engineering topic. I want you to always encrypt the keys. I want to be able to look at the keys. I don't know. That's a little silly, but how would we approach it?

I'll give you an example, right? So, regulations in the US are very different from regulations in Germany, for example, and regulations in India. We have customers who have businesses across different parts of the world, which means they're using our capabilities They're using the public cloud instance to meet requirements in India, in Brazil, for example, Germany, and the US. The way we partition these solutions out or these Lego blocks out is we actually create solutions that are tailored to each market. For example, we have a product called Assured Workloads. Assured Workloads has instances in different markets. As a customer, I could say I'm using Assured Workloads US regions and support or Azure Workloads IL4, IL5, in which case that subsegment or the projects and the folders that I'm creating within that have the guarantees of IL4, IL5. They're supported by US personnel that are cleared. We have data residency, the right level of access transparency, and then the monitoring and everything required for an IL4, IL5 instance. The very same customer could turn around and say, I'm an ISV, I'm also going to have operations in Germany, for example. In that case, they would basically use an Assured Workloads version in Germany that is tailored to the requirements for the German market, which means all the folders, subprojects, everything created within that instance will meet the requirements that are put in place or the policies that are put in place against that particular regime that we're talking about. creating these logical separations, and you still have customers that could have one instance of the cloud with various sub-partitions within that that meet the needs of the different markets that their business operates in.

Okay, that makes sense. And I think that to me, this means it's still not easy, but at least there's a logical path to that.

It's a 5-minute enablement. I'll give you an example. We had a US public sector customer that wanted to have operations, for example, in another part of the world. They needed it for a mission, they needed to bring up their workloads, and they needed it for a very small period of time. Imagine if they were on GovCloud. We would have said, we don't have a GovCloud in that country. I'm sorry, we can't give you the same level of guarantees that you want. Instead, we said, great, we have that region, we have a region in that place, we're going to add that region as part of your policy, We're going to bring up that instance for you, for you to start creating your project in your folder in less than 5 minutes. We're going to get the encryption keys set up to your old encryption keys that you already have. If you need a local version, we'll set that up. Now you're ready to go deploy your workloads. Anything that goes under that workload meets the requirements of that country. Once you're done with everything and you want to delete stuff, you just turn it off and at that point you don't have that instance. The scalability of this is far easier than you would ever get on a GovCloud because you can have people turning on their workloads in any part of the world and still have it meet the requirements that they might have locally for that country.

That to me makes a ton of sense, and I love the contrast with the difficulty of working in a GovCloud model. I've enjoyed this conversation tremendously, and I hate to do this, but I have to ask our traditional closing questions. So, one, do you have a tip for leaders out there? And then 2, do you have recommended reading? It could be about anything. We've had people recommend everything from Mary Oliver to The Art of War to— well, not Anton's blog.

That's right.

Hold on. Let me think.

Yeah, it's quite a bookshelf behind you.

That's right. Yes. Okay. So, she's going to kind of cheat and pick a book from the shelf and say, This one.

I actually like Good to Great, but a lot of people have actually read Good to Great. Appreciative Leadership is one that I actually enjoy. It's a book that I often refer back to. It's one that I feel is interesting for me at various stages of my leadership journey. I've actually looked at Appreciative Leadership because the one thing that we forget to do often is we run really fast. We have so many things that we all tackle on a day-to-day basis. And sometimes, you know, taking a pause and taking a moment to think about how you recognize your team is a super important thing that leaders should care about. And this book is great. Like, it has several aspects that I've used in my everyday life.

I love that answer, and I will go get myself a copy of Appreciative Leadership. I, for one, am appreciative that Archana has joined us today.

Thank you so much for having me. It was a pleasure.

And now we are at time. Thank you very much for listening and of course, for subscribing. You can find this podcast at Google Podcasts, Apple Podcasts, Spotify, or wherever else you get your podcasts. Also, you can find us at our website, cloud.withgoogle.com/cloudsecurity/podcast. Please subscribe so that you don't miss episodes. You can follow us on Twitter, twitter.com/cloudsecpodcast. Your hosts are also on Twitter, @anton_chuvakin and @_timpeacock. Tweet at us, email us, argue with us, and if you like or hate what you hear, We can invite you to the next episode. See you on the next Cloud Security Podcast episode.

Security.