 Hello, everyone. Welcome to this session where we are going to discuss how to use global cloud infrastructure for speed and compliance. And they will review how to achieve that while designing and building geo-distributed applications. So before we start a little bit about myself, my name is Denis Magda. For the last eight plus years I've been working with distributed databases and high performance computing systems. Currently I am the head of developer relations and Ugabyte. If you don't know, Ugabyte DB is a distributed SQL database that is built on PostgreSQL source code. Before Ugabyte DB, I worked and contributed to ApacheNet community that develops another distributed database, but which is designed for high performance and memory computing. Before distributed databases and high performance computing systems, I worked on the Java engineering team. I was developing GVM and GDK, rhetorical, and also my professional career started at Sound Microsystems where I was on the technology evangelism group. So speaking about our primary agenda for today, first we need to discuss how global cloud infrastructure is useful and can be leveraged for the speed and compliance. After that we will remind ourselves how a typical cloud infrastructure looks like. We will select, let's say, just a random provider such as Google Cloud Platform and finally we will discuss how to build those geo-distributed applications for speed and compliance by discussing the topic of geo-distributed applications. Okay, let's move on. So when global cloud infrastructure comes handy? When can be leveraged? The first thing is when you need to equalize latencies for users around the world. So let's take this example. Pretend that you're building a Slack-like messenger. Yes, a corporate messenger. Probably we are doing too much by reinventing the wheel. But who knows, I might have some killer feature in mind. But on a serious note, Slack is a good example of geo-distributed applications that runs globally, can withstand various outages and perform equally well around the globe. And let's say right now I'm building a Slack-like messenger and I have the first instance and version available. That version is deployed in the United States and it comes with an application instance and also a database node that keeps all the data. And I've got the first three users of my applications. Those are friends from the college times, but they live in different places and on different continents. Please welcome Mrs. Blue, a financial advisor from New York. Next, please welcome Mr. Green, her friend, a scientist from Berlin in Europe. And also we've got Mr. Red who moved to Mumbai and he is a professional writer. So one day they decided to use this Slack-like messenger. And the problem is the following. For Mrs. Blue, who lives in New York, the latency for her request will be extremely low. It can be as low as five milliseconds because she lives in New York and I have my primary instance of the application and database deployed somewhere in the US east region. And why five milliseconds? If to take Google Cloud platform as an example, if the resources and virtual machines and your users are located within the boundaries of a single region, then the latency can be as low as five milliseconds. However, the latency for Mr. Green, who also wants to join a chat with Mrs. Blue, will be much higher. It's gonna be around 98 milliseconds. Just because, let's say, his requests needs to travel through the Atlantic Ocean. Yep, there are some lots of physics that we cannot beat that easily. For Mr. Red, the situation will be even worse than for Mr. Green because he is located in India right now. And when he joins the chat in our Slack like messenger, his requests, I will travel a much longer distance. So the average latency time, round trip latency time for his request can be as high as 270 milliseconds, right? So that's the first problem, right? If you're building, I'm building the Slack like messenger, and I have the right vision, even though right now, my application is running in the United States, I already getting the global user base. I have users around the globe, and for them, the latency is high. Another second problem that usually exists when you're building applications for the global user base is that in some regions, you need to comply with data regulatory requirements. Let's review this case. You know that Mr. Green lives in Berlin, in Europe, and it's highly likely that you have that you heard about JDPR, General Data Protection Regulations law that was signed in order by European Union Loan Taminga. And according to that, to the JDPR, all the personal data of Mr. Green has to be located in Europe. But right now, according to my architecture, my first version of the application, the data of Mr. Green will be in the United States because that's where I have the database running. And here is we kind of probably hearing, let's say the first month or even years when my application will be up and running, that's not going to be a big deal. If I have, let's say, just Mr. Green or a few other folks from Europe using my application, but once I start expanding in Europe, that's going to be a big deal. All right, that's JDPR, and it's highly likely that you have that you've heard about these regulations. However, Europe is not alone when it comes to the data privacy and torsional data protection. In India, several years ago, the Reserve Bank of India put in place another law that requires to keep all the payment data of Indian residents and citizens in India. What it means? It means that if in our slack like messenger, we are going to introduce, you know, some features that you can buy like stickers or probably money transfer from Mr. Red to Mrs. Blue or to Mr. Green, then all of those payments transactions can be processed in the United States. But the data payment data, all those transfers, deposits, credits, all the data have to be have to reside in India and not in the United States. Again, probably for the first version of my application, that's not a big deal. If Mr. Red is the only one customer that I have, but as soon as I decide to grow in India or in the rest of the countries in that region, again, this is going to be a big problem for me, for my application. However, the good news that when it comes to the low latency across the globe and compliance with data regulatory requirements, we can use global cloud infrastructure to architect and to develop and to deploy our geo-distributed applications properly. So right now, let's quickly remind ourselves how a typical global cloud infrastructure looks like. So first thing first, usually every cloud, at least public cloud, consists of regions and regions are independent geographic locations that are scattered around the globe. It's highly likely that you've heard about US West, one region or Europe West, two or US East, like North Virginia region, etc. And those regions are interconnected through a regional network. If to take again Google Cloud Platform as an example, the latency, the round trip latency time between Oregon, US West and South Carolina, US East is relatively fast. It's like 65 milliseconds for the round trip, which should satisfy the requirements for most of the applications unless we are dealing with different trading platforms. However, as soon as you are moving farther, right from the United States, the latency will increase because the requests have to travel through the land, they have to travel under the ocean, etc. For instance, if you have the latency time between South Carolina, US East and Frankfurt, it's 97 milliseconds. But from Mumbai to South Carolina, it's already 270 milliseconds, right? So this is something that you need to keep in mind when you start building applications and deploying databases that spawn across multiple regions. And we will discuss what are the techniques that you can follow in several minutes. Then if to zoom into a region, if let's say to select US West as an example, Oregon, then every region consists at least of three availability zones. And as the name suggests, availability zones promise to increase and to improve availability of our applications. If you take advantage of those availability zones. So that's why on average, every region comes at least with three zones. Because if one zone goes down, then your traffic and the request can quickly be redirected to the zone that is nearby. And the zones within a single region are interconnected through a high performance network. Again, if to take Google Cloud Platform as an example, the round trip network latency time is under 5 milliseconds on the 59th percentile. And that's extremely great, right? And finally, just to complete the story, regions consist of zones, right? But also in addition to zones that are interconnected through a high performance network, we have local or edge zones. And those zones expand the cloud infrastructure to densely populated metropolitan areas. Take London, take New York, take Seattle, probably take Austin, Texas. If you pick a cloud provider, you can check where an edge or local zone is located. And usually those zones are used by applications who require a single digit millisecond latency for their end users. As an example, streaming or gaming applications, right? They use those zones a lot. Finally, you see that this global cloud infrastructure is diverse, right? It's available across the planet. And there are different latencies of time between different regions. And when you look into a specific region, you will see that among the zones, the latency is always low around like 5 milliseconds for Google Cloud Platform. And what it gives to you, it gives you an ability to architect and build applications that truly provide similar performance and latency to users across the globe, right? If I build my Slack like messenger, I want the latency time to be the same for Mr. Green, Mr. Right and Mrs. Blue. I want all of them to say that my Slack like messenger is really fast. I don't want any of them to say that, oh, it's slow. And the slowness will be because of Mr. Right is located in Mumbai. And his request needs to travel all the way to the United States. Also with these regions and availability zones, you can comply with data residency requirements, JDPR or other payment data protection that is imposed by the Reserve Bank of India. Those are just two examples. And also, you can truly tolerate different cloud failures, including major regional outages. In this session today, we are going to discuss on the items number one and number two. But when it comes to the cloud failures, regions exist for reason, right? Because usually you want to use one of the regions because you expect your users to live nearby. But right now, truly, you work in the global space. Even if you have your application and database running, let's say in the US West, it doesn't mean that you will not have users from the US East or from Europe, right? It's highly likely that you will have, depends on your application for sure. And what's also important to know here, regions do fail. Availability zones fail all the time. That's normal. But also, regions do fail frequently. You have to take AWS as an example starting 2011. AWS alone had at least one major regional outage at least once a year. So this is happens, right? And you just need to be ready for those failures and you want so that you can withstand them easily. Now, let's remind us what we have. We have, we are building applications that are used by global user base, right? And we want to provide the same speed and latency for our users. And we also want to comply with data regulatory requirements. And we can easily achieve this with global cloud infrastructure. So now let's talk about geo distributed applications, because those applications are the apps that span multiple geographic locations for high availability, compliance and performance. And today we are talking about compliance and performance. In practice, what it means? It means that you might have application instances deployed in all of the continents. Or if you're developing, let's say something just for their United States market, or for the late in America or for Brazil or for Argentina, you can deploy multiple application instances on that continent, right? But with that architecture, you can always scale beyond the boundaries of your continent, where your application is running right now. So, and when we're talking about a typical architecture of a geo distributed application, how does it look like? Surprise, it comes with the same components as regular applications. And the regular application is the one that you usually run in a single availability zone. But the difference is that all of the components of a geo distributed applications, they have to be highly available. They have to perform fast across the globe. And they have to comply with data regulatory requirements. So what it means for the data layer that keeps our data, it has to be distributed. You cannot just, you know, run one instance of a database in a single availability zone. Why? Because that zone can go down at least. Or because some of the data needs to be stored in Europe to comply with the JDPR, and not in the United States. For the application, what it means, you can build, it doesn't matter whether you're building a monolith application or an application that is split into multiple microservices. What matters is that for your for each of your monolith application, or for each of your microservices, you need to have multiple instances running across the globe, so that user requests are executed faster. And so that you can withstand different outages. And finally, global cloud load balancer is an excellent component that you need to take advantage for the geo distributed apps, because it can provide you with any CAST-AP address. And all of the user requests will be sending the queries to that global load balancer. And load balancer will forward those requests to the application instances that are closest to your user. Okay, we will review how it happens in a second. So right now, let's take this, let's put this in practice. You remember that my first version of a geo distributed application is deployed and runs in the United States. That's where I have my application instance running in a database node. And according to the rules, I need to have multiple instances of my application running across the globe, right? If I want to support the global user base, right? It's easy to do. I just take and deploy an instance of my application in Europe and Asia. And after that, also, I go ahead and configure the global cloud load balancer. Once I do this, this is what will happen. Remember, we have Mrs. Blue, Mr. Green and Mr. Red. When Mrs. Blue sends any requests, for instance, she uses our mobile application of front end, web front end, the mobile app or the front end will connect to the global load balancer. And the global load balancer will determine, all right, the request is coming from Mrs. Blue, and Mrs. Blue lives in New York. That's why her request will be redirected to the instance of the application that is in US East in North Virginia. For Mr. Green, the situation will be similar. When Mr. Green opens our chat in our Slack like messenger, then the global load balancer will figure out that, all right, Mr. Green is in Berlin, and I have an instance of the application running somewhere in Europe. So his request will go to that instance in Europe. And the same is true for Mr. Red. Okay, so we solved the first problem, right? So generally speaking, right now, with the usage of global load balancer and with multiple instances of our applications, we can easily redirect the user traffic to the closest location of our application instance. However, still, according to this architecture, we have a database note running just in the United States. And this is bad. And this is bad from the performance standpoint, and from data regulatory requirements. Because for Mr. Green, even though the instance of the application in Europe will be processing Mr. Green request, that application will go to the United States to get any data to send any changes. So for instance, when Mr. Green wants to read the history of conversation, then all the data needs to be read from the United States. So when Mr. Green needs to send their message, again, the data needs to travel to the United States. And again, the latency is going to be high, right? Mr. Green can compare, can complain from time to time that the application is slow. We don't want this to happen, right? Which means that a quick fix is to figure out what to do with the database. And that's probably the most complicated component here. Because data, you need to decide right where to store data, you don't want to keep, you know, a lot of the duplicate copies of your data and also there are a ton of other things that you need to consider when you deploy a database instance across multiple regions. But generally, as a quick fix, we need to do this. You need to deploy, it needs to be designed in such a way that the application instance from Asia, from Europe somehow can read or write data much faster by working with an instance of the database that is located in their regions. So this is what exactly we need to achieve. But this is a little bit longer in conversations. So now, because we started talking about multi-region distributed database deployments, right, folks? And there are several versions. So throughout the last, like 10 or 15 minutes, we'll review four options because there is no any server bullet. And you will pick multi-region database deployment depending on your use case, right? At least you need to be aware of the options. First, you can run a single multi-region database cluster. We will see how it happens. After that, you can deploy, you can still run the single multi-region cluster in your primary location, such as, you know, United States, and then you can provision read replicas in distant locations. Why do we do this? We'll discuss. Also, you can deploy multiple standalone database clusters, one in the United States, in Europe, and in Asia. But there are always trade-offs, right, if you do this. And finally, we will talk about a so-called dark horse about geo-partitioned database cluster. That is something new that is available in modern databases. I will be using, when we will be discussing all those types of deployments, I will be using UGByDB as an example. And if to give you a quick introduction to UGByDB, it's an open source distributed SQL database. It's built on the PostgreSQL source code, and it's inspired by Google Spanner. What it means that it's distributed, it's scalable, comes with automatic sharding. It supports RAV for the consistency, it runs distributed transactions, and it's built on PostgreSQL, which means that you can easily move your existing applications from PostgreSQL to UGByDB whenever you need one of the following. If you want to withstand various cloud outages, if you want to scale easily by adding new nodes to your database deployment, and when you need to serve user requests with low latency, across multiple regions, across continents as an example, and finally when you need to comply with data residency requirements. So if to talk about the PostgreSQL compatibility, then how compatible UGByDB it is. So here is in green, you see our SQL engine, and this SQL engine literally is PostgreSQL. That's our query layer or compute layer, as some other databases define. And in red, we highlight those components of the SQL engine that we enhanced in UGByDB, in optimized in UGByDB, because we need to have planner, optimizer, and executor who are aware of our distributed storage, so that whenever you execute your SQL queries, then those SQL queries know how to run, how to run, how to be executed across multiple nodes that might spend multiple availability zones or regions. So now let's talk about the first type of multi-region database deployment. This type of deployment is important to highlight, is used to tolerate region level outages. So in this example, what I have for the sake of simplicity, I deployed a three-node cluster, and I have an instance of a database in the US West, US Central, and US East. And every node is equal. We don't have any leader of follower concept here. Every node keeps a copy of the data, some of the nodes keep the primary copy of the data, some of the nodes keep the backup copy of the data. But generally, every node serves reason rights. And this is how you can utilize all of the resources of your cluster. Changes are replicated synchronously. And there are always several optimizations, how you can minimize latency. When, for instance, you process update in the West, then you need to replicate this change to the US Central and to the US East. It's all easy to do. So we're not going to discuss how to tolerate region level outages today, but if to give you an example, this is something that many, many companies used. Probably you heard about a snow storm that happened in Texas, in the United States, probably a year or two ago, and during that storm and blizzard, the whole power grid went down. And also, many data centers and many applications that were deployed in the Central became unavailable. But one of the largest retails in the United States easily reached that outage. They didn't didn't experience any downtime at all, the case, even though their database nodes of Yucca by DB went down in US Central, the whole database was running because they had another nodes deployed in other regions of the United States. So this is at least how you can use this type of deployment to withstand regional outages in the cloud. But now let's return back to my geo messenger application. You know that I have Mr. Green and Mr. Red. And probably I came to this milestone of my application when I already have thousands and thousands of active users daily in the United States. And right now we decide that the time has come to expand officially our geo messenger to Europe and to India. My architecture is actually ready because I were designing a geo distributed application, I can deploy multiple application instances across the globe easily. And if needed, I can expand and span yoga by DB across the globe. But when it comes to the global deployment, the easiest way to start is with read replicas. Read replica is a node that keeps a copy of your data. And with that read replica node, you can accelerate reads in distant location. And then the easiest operation to do is for instance, someone decides, right, we have a big user base in Europe. What can how can we boost the performance there? If reads are enough, then just deploy the replicas. If you need to accelerate rights, then this is what you will discuss on the next slides. But this is what you can do easily, right? And the data will be stored and the data will be read from those read replicas. All the changes are sent asynchronously from your primary cluster to your read replica nodes. Okay, those changes will arrive with some delay. But anyway, on the read replica side, you will have a consistent copy of your data. In the cases when you need to accelerate and improve the performance and latency for both reads and writes, you need to consider other deployment options. The first one is also pretty standard one, you go ahead and deploy multiple standalone database cluster. So what do we have on this picture? We still use the same database cluster in the United States that can tolerate different outages. But for the for the European Union and for South Asia, we deployed separate clusters. And in this case, you already comply with data residency requirements because of the all of the data of Mr. Green will be located in Europe and for Mr. Red, the same all of the data is in Asia. And the performance of reads and writes also obviously would be fast. What are the trade-offs there? The thing is that with this type of deployment, if your application needs to access needs to get access to all of the data, then you need to your application layer needs to to maintain multiple connections to all of these databases. And then when you need to join data, merge data, then that that have to be done at the application layer that might be a pain. Also, when you need to synchronize changes, if you need to synchronize changes, then you need the changes will be synchronized synchronously, which might be good for some of the use cases. But actually, for my geo messenger, this solution doesn't work. Because what happens is that I might have in my select like messenger, I might have a channel that is located in the United States. So like all of the messages that are sent to this channel will be stored in the United States. And this channel is used by Mr. Green, Mr. Red and Mrs. Blue. I want Mr. Green also to see the channels and to send messages to the United States, right? Why not? Because that's my global select like messenger. So for my use case, it means I want to use single geo partition database cluster. Again, here is I have a single cluster. This cluster consists of nine nodes. I have three nodes in the United States, three nodes in Europe and three nodes in Asia. And every node keeps the data that belongs to its region. For instance, and this is what you as an application developer need to define in my table. Let's take that this is the message table that keeps messages. I add a special column that is named region. And if the value of the region is equal to EU, European Union, then this message, this record will be automatically placed in on the nodes that are located in the European Union. And then whenever Mr. Green will be reading any messages from that are stored in Europe or sending any messages that are stored in Europe, updating his personal data, all of those requests will be automatically handed by these nodes that are located in Europe. And from the applications standpoint, your application doesn't need to have multiple connection endpoints to multiple databases, because what you have a single database, you are free to maintain a single database connection. And then whenever you need to merge any data, you will need to join any data Mr. Green needs to send a message to a channel that is stored in the United States. It's all possible to do through a single database connection. And again, similar to the previous deployment type with geo partition database cluster, you can accelerate reads and writes, you can certainly comply with data is residency requirements and also you can easily access all of the data right by using a single database connection. So now let's quickly do a demo break. We have five minutes left. What I want to show you, I want to briefly show you read replica, how you can truly improve the performance with read replica nodes. So what I have here, I have a database cluster running. That's you go by DB. I have the primary nodes deployed in US East, South Carolina, a three node cluster that can withstand zone level outages. And also I have a read replica node deployed in Asia East in Taiwan. Also, I will be running my SQL queries from this node, Asia East instance that is deployed in Taiwan as well. So here is this terminal, what's connected both terminals, I logged in SSH to that instance in Asia. So this is somewhere in Taiwan and this is as well. And this psql session is open to a UGA by DB node that is deployed in US East. But the second session is to the read replica node. So pretend that we are dealing with Mr. Red. And this is an option when Mr. Red needs to send his request to my geomessenger when all the data is located in the United States. But this is the use case when Mr. Red can read the conversations much faster through the read replica node that is available in his region in Asia. So let's do this check first. I want to make sure that we are connected to the same database cluster. And it's easy to do to by running this SQL request. So like this connection here, we have three primary nodes in US Eastern, we have read replica in Asia. And now I have this simple request. Let's say that right now Mr. Red wants to read all of them messages like if we have 42 messages in one of the channels. And it took 200 milliseconds to get to complete this query. Because again, this is the machine that is in Asia. And this machine from Asia sends a request to the database node that is in US East. And now if you execute the same query from the same machine, which is connected to the reader replica node, the performance is much faster. It's like tens of like 20 times faster. Just because all the data that is required for this query is located locally in this region. Also with reader replicas, it's important to know that Mr. Red still can send changes, right? Mr. Red can send messages to my database. And my application doesn't need to maintain another connection to the United States if I want to update any records. Let's do this experiment. Let's, I don't know, check this channel. Yeah, that's one of their channel that exists. Yeah, it's deployed in Japan, somewhere in Asia. That's the name of the channel. And right now, first, I need to allow writes from my reader replica node so that the reader replica node can send updates. And right now, let's insert another channel. So when we insert the channel, what happens? The reader replica node receives this request from your application or from this past quail connection. And it will forward this request to the primary cluster automatically. So you don't need to care about that. Why it took so long? Because in fact, I have special sequences. And those sequences are stored in the United States. So like here is when I was inserting the first record from through the reader replica. The reader replica went to the United States and booked the next range for my IDs. And that took time. But if I insert the next, let's say record, then it will be faster. It's like 10 times faster. Yes, we can insert it several times because right now I have IDs. But still their latency is around, let's say 700 milliseconds, because still that request needs to travel from Asia to the United States. And then in the United States, that request is synchronized and replicated across multiple nodes, right? This is what happens. But anyway, this is how you can boost the performance for reads because reads to remind you extremely fast when it comes to the reader replica nodes. All right, if you need to boost writes, you know what to do. You can deploy multiple standalone clusters in different locations, or you can provision a geodistributed cluster. But that's the next story. We don't have time unfortunately today to demonstrate how it works in practice. What we have time for is to briefly discuss what database deployment time you need because we discussed, let's say, three, four, right, different options. If you need to comply with data regulatory requirements, then your option is a single database, like your option is as follows. You need to pick either geo partition cluster or multiple standalone clusters. So here is how to decide if you want to have a single database instance, right? You want your applications to maintain a single database connection and you want to easily access all of the data, then probably geo partition cluster is the way to go. Otherwise, you can deploy multiple standalone clusters. If to go back, if you don't care about the compliance, then ask this question to yourself, do you need to accelerate reads or writes? If you need to accelerate just reads, then deploy a multi region cluster and then attach reader replicas to this cluster in distant locations. But if you need to, again, boost both reads and writes, then you have to pick between the geo partition cluster of the database or multiple standalone clusters. And another important takeaway. In today's presentation, I took a geo distributed messenger as an example and that might be the extreme example because we were talking how to improve the speed and compliance across an application that runs across the globe. But in your case, your global kind of application definition might be within boundaries of a continent. And which is fine. For instance, when you deploy your application, the first version of the application, it doesn't need to run across the globe, right? But at least be ready for that. So that make sure that your application at least runs across multiple availability zones, like it's shown on this picture. For instance, I have US East region. And within that region, I have nodes deployed in different availability zones. The latency is fast around five milliseconds for Google Cloud Platform. And I can withstand zone level outages. And this is how I can approbate and test my geo distributed application that runs within a single region right now. Because once the time comes, once the manager comes and says, all right, now you need to scale to Europe, or you need to scale across the country, then you will be ready from the architect just in point. But again, my advice, when you deploy the first version of your application, take advantage at least of multiple availability zones and be ready to scale beyond a single region. And finally, if you want to learn more, I would recommend these two books by O'Reilly, architecting for scale and designing data intensive applications. It's an excellent start. And if you're interested in the database deployment options, and take a look at Yugabyte, we have developer's hub and Yugabyte db university. Wonderful. You have two minutes left. And I'm ready to answer on your question. Please, go ahead and ask.