Hello, Cloud Gurus. You can tell that this month's announcements are a pretty big deal because Google's two new cloud regions coming online aren't even the biggest stories! That honor is shared by Google's new AlloyDB product that competes with Amazon's Aurora database and their new service to dramatically improve the security of your applications by, well, maybe I shouldn't spoil the surprise. Stick around to the end to find out. I'm Mattias Anderson and you're watching GCP This Month from May, 2022. First up, let's talk about those two newly opened regions that I mentioned.

The first one is in the Madrid region of Spain and is called europe-southwest1. The second one is in Columbus, Ohio and is called us-east-5. Yes, this is the fifth Google cloud region in the Eastern USA. And that doesn't even include the two further regions in Eastern Canada. This brings Google's new global total to 33 regions made up of 100 zones. And since we're counting,

they also have 146 network edge locations around the world. Shall I read those to you? Hmm they're in Ashburn, Virginia, Atlanta, Georgia, Chicago, Illinois. yeah. And 143 other places. Another cool thing Google has done this month is to give BigQuery the ability to call your Cloud Functions as a part of its query processing. Now, you might wonder why you would choose to use this paid option over the free one of built-in user defined functions or UDFs. Right? Well, one reason is that the built-in ones only support JavaScript or SQL, whereas Cloud Functions support a whole bunch more languages.

But another reason is that the Cloud Functions can call out to other services and let you do things like interact with external tokens, and that could dramatically simplify some compliance requirements that you might have, just as an example. This month Google's new Spot VMs are generally available as the replacement for Preemptible VMs. You can still use the old ways of creating Preemptible VMs, but those will now be charged according to the new variable pricing model of Spot VMs. Preemptible VMs used to have a fixed cost, but the prices for Spot VMs move around depending on demand. So check out the blog post we'll link to spot how those details might apply to you. Okay, let's finish off our quick bites with a few rapid fire updates

so you can decide whether you want to go and read those articles for more info. Cloud Logging has just gotten some new simpler options for querying and your custom queries will even update the field pickers in the UI if they're not too complex. Cloud TPU VMs are now generally available. So you no longer need to use another compute engine instance to access those tensor processing units. Google has been named a leader in the 2022 Gartner Magic Quadrant for cloud AI developer services. And you can now use N2D and C2D instances with Google's confidential computing offering that keeps your data encrypted, even in Ram. All right,

with that, let's move on to our gems for this month. Our first gem is Google's shiny new AlloyDB product for PostgreSQL. Shiny. Yeah, yeah. This offering seems to fit in between Cloud SQL and Cloud Spanner. And although they refuse to use clear terms in their marketing post about it, Google is obviously intending this to compete directly with Amazon's Aurora database and lure people away from Oracle. Their article begins by saying,

quote, enterprises are struggling to free themselves from legacy database systems and need an alternative option to modernize their applications. And in the second paragraph, they claim that in our performance tests, AlloyDB was also two times faster for transactional workloads than Amazon's comparable service. Okay. The first thing I need to make clear about AlloyDB is that it is currently in preview. So it's not really fair to draw lots of concrete conclusions about it just yet, but I think there is still value in trying to answer some of the most likely questions about how it works and how it might fit into people's architectures once it's ready for prime time. For the question of how it works, we can turn to Google's articles about it.

The announcement post that I already mentioned doesn't get into all of that much detail about this, but Google has helpfully written another article that explains how AlloyDB is built to have a PostgreSQL processing layer that uses a new database aware storage layer that is in turn using Google's distributed file system. What this extra layer means is much better separation between processing and storage and, for what it's worth, this seems a lot like how Amazon has structured Aurora. A second under the hood article though describes how AlloyDB uses a column engine that reminds me more of BigQuery or Amazon Redshift, or notably, Oracle offerings. And this is likely why Google can claim that, quote, in our performance tests, it's more than four times faster on transactional workloads and up to a hundred times faster on analytical queries than standard PostgreSQL. Now, this is definitely all very interesting, especially the bit about analytical queries being a hundred times faster, right? And Google also says they will offer a 99.99% availability

service level agreement when they go generally available. And that includes maintenance because AlloyDB automatically detects and recovers from most database failures within seconds, independent of database size and load. I do need to temper things a bit though, because this is an early offering. And I don't just mean because it's still in preview. I also mean that for it to compete directly with Amazon's Aurora, it seems to have a lot of catching up to do in some other areas. For example,

I haven't found anything yet where AlloyDB could replace Aurora's global database. That still seems to be an area better handled by Cloud Spanner. Also, because AlloyDB seems to require you to provision and manually scale instances to handle capacity, its minimum monthly cost looks like it will be a lot higher than Aurora Serverless V2, which can theoretically scale down to almost nothing, just the storage. But I wouldn't write AlloyDB off yet. It certainly seems like it will have a place in some architectures when it's released. And I'm sure the Googlers are already busy working on making it even better too. The last thing I want to cover in this episode is Google's announcement of their upcoming new Assured Open Source Software service, also known as Assured OSS.

Now this name might first strike some of you as pretentious mumbo jumbo, but I wanna tell you why I think this is a really big deal. Now let me start off by explaining the problem. Currently in software development, we all use publicly available packages, modules, libraries, frameworks, and what have you to build our applications. Trying to build everything without the support of open source projects would put us at such a competitive disadvantage that that's only ever done for the most restrictive and bureaucratic projects, all the rest of us move forward and get our work done. But by incorporating code that we haven't written and don't control into our apps, we are giving those who do control that code the power to affect us.

And we certainly do get affected. Remember how the creator of leftpad pretty much broke the internet for a while in 2016? If you're not familiar with the story, read the article we'll link in the video description. But that's just one example. Of course, now there are some things that we can do to mitigate this issue, like pinning version numbers in our build files so that we only include versions of packages that we've reviewed as safe. Although actually that wouldn't even address an issue like unpublish leftpad.

Instead we need to make our own copies of those packages and manage them ourselves. But uh, hmm. Then those packages use other packages too. So we need to include those dependencies and so on almost forever. I'm not exaggerating when I say that a simple hello world application might easily pull in hundreds of thousands of other people's lines of code and a change to any one of those lines of code might turn our app into malware. So we arguably need to review any and all changes, but this is clearly a nightmare. The whole point of using these packages was so that we could get our work done, right? Not trade one problem for another.

And this is the whole point of Google's upcoming Assured Open Source Software service. Google already has teams of people responsible for doing all of the careful reviewing I mentioned because they're a massive company. And, sure, you would still not be reviewing all of those things yourself if you use the Assured OSS service, but I'm sure that Google will do a much better job of reviewing all that than I would myself. Besides, I just don't have the time. Okay. As for the service itself, you can read the article we'll link in the description to learn more about how Google scans, analyzes and fuzz tests the packages, then builds and signs them and distributes them through Artifact Registry. Google notes that Assured OSS is expected to enter preview in Q3 of 2022. Well, that does it for this month.

I hope that you're getting value from these updates we keep bringing you and if you are, please do let us know. Well, I hope that wherever you are, you have a really great rest of your day. Take care of those around you and keep being awesome cloud gurus.