All right, let's talk about geodistributed applications and see how to build those by using the global cloud infrastructure. In this session, we are going to talk about high level architectural design patterns and consideration. This session is not tailored to any specific programming language. Instead, we will see how to build those applications, how to design the data layer, how to arrange our microservices, and there are other parts of the application stack. But then when it comes to the development, it will be up to you. You will decide how to take these design patterns and considerations and implement with your favorite programming language. All right, so, speaking about their agenda, we will walk through three steps. Step number one, we need to remind ourselves of the global cloud infrastructure that is provided by major cloud vendors. We are going to talk about different resources, about regions and zones. After that, we will do an introduction to geodistributed applications, how those applications are different from standard applications, what are the benefits, what are the tradeoffs? And eventually, with step number three, we will practice in designing and architecting a geodistributed application by taking a slate like corporate messenger as an example. Okay, so the global cloud infrastructure when it comes to the infrastructure, you know that every cloud provides various resources. We have virtual machines, we have network, we have disks and other types of hardware. And those resources are grouped and located within regions. A region is an independent geographic location, such as US west one, Europe west two. On this map, we have regions in North America and South America, Africa and other continents. When it comes to their speed and latency within your region, all the resources of a single region are interconnected through a high performance network. But what if you need to send, let's say, requests from one region to another region? The latency will vary. The latency will depend on how far each regions are located from each other. If to take Google compute platform as an example, then the numbers as follows. Let's say that we have an instance of application running in Oregon us west, and we want to send the request and get an acknowledgment or response from North Virginia. The average round trip is around 60 milliseconds pretty fast, right across the country. But if the same application from Oregon needs to send a request to London, the latency will double. It will be around zones hundred and 30 milliseconds. The latency will be even worse. If our application from Oregon needs to go to Mumbai in India, the latency will be around 220 milliseconds. But at the same time, if your application needs to go to Tokyo through the Pacific, somewhere here, then the latency will be 90 milliseconds, much faster than a request and response to and from Mumbai. So what the conclusion can we make? All the regions are interconnected through different networking channels. Some of the channels are faster, some of the channels are slower. That's why when we will be talking about geodistributed applications, the components of those applications, such as the data layer, application layer microservices will span across the globe. And you need to be careful about when you pick specific remote regions because you have various regions and the connectivity between those regions varies. Or you need just to apply different patterns that we are going to discuss going from the regions. Every region consists of zones and zone is a separate physical location within a regions. So on this map we have proximity boundaries of the US west zones. We have three zones in this regions. And usually you have three or more zones for the high availability needs. If you, let's say deploy your application, your solution across three zones, like instance of the application such as NgINX web server is running zone one, zones two and zone three. Then you can withstand zone level outages. If this zone goes down, your application web server is still running because it's running in other zones. That's why we have zones. The latency between the zones is extremely low. All the resources within the zones are interconnected through a high performance network. If to refer to Google cloud platform again, and to talk about Google's infrastructure, then the round trip network latency is under 55 milliseconds on the 95th percentile. And that's extremely fast. It's just the round trip between the zones. And finally, we have regions. Every resources within a region are scattered across the zones. But also many cloud providers expand their infrastructure to densely populated metropolitan areas. And they have services or like products named as local zones or local edges or edge nodes. What's the purpose of those local zones? They are usually required for applications that are looking for single digit millisecond latency for their end users. The best example here is gaming applications or streaming applications. So if you have a lot of the users who live in Seattle, Atlanta, London or New York, you want them just to consume, to use your service the fastest way possible. And you want to store the data. You want to run instances of your microservices the closest way possible. That's what those local zones are designed for anyway. As you see, the global cloud infrastructure is really broad. And with that infrastructure, we as architects can design and build application. They have several characteristics. First, your global or geodistributed applications can provide similar performance and experience to your end users without, regardless of the user's whereabouts. So let's say that you have an application, and originally this application was launched in use by your customers from Europe. But right now it's gaining popularity in Asia and you want your users from Asia to have the same level of experience as your european users have. And with the global cloud infrastructure, it's extremely easy to do this if your application, your data layer, your application layer parents and also exists, has a representation in your asian data center. The second benefit of the global cloud infrastructure that we can take advantage of is you can comply with data residency requirements. Let's take another approach. Let's say that you launch an application primarily for APEC asian market, but right now you see that citizens from Europe kind of looking at it, you see a lot of the demand from Europe. And if you want to launch and expand this application to Europe, it's highly likely that you have to comply with the local requirements such as GDPR. And again, the cloud infrastructure allows us to do that. Right? You can have, let's say you can keep the data of your application in the european data centers and you can deploy instances of your microservices. The only topic that is left is how to architect such a geodistributed application. And finally, with this architecture you can tolerate cloud failures. For instance, what if, let's say you have us west and you have a region in US west and you have a region in US south? If the region in US west goes down, your traffic for north american users can redirect it to another region. It's possible to do. It's all about how to implement it, as can application and data layer. The infrastructure exists. Having said that, let's do a quick introduction to the geodistributed applications. A geodistributed application is the application that spans across multiple geographic applications. For what reasons? For high availability, compliance and performance needs. On this picture, we will start talking about our geodistributed corporate messenger. And this picture shows that our messenger instances and components of this solution run across the globe. We have North America, South America, Asia and other locations. But let's quickly step back and review what are the downsides of standard applications, the applications that are usually deployed and run in a single vulnerability zone of your cloud environment. On this picture we have the same corporate messenger, but it's deployed in one of the regions and it's deployed in one of the availability zones. That's a default actually deployment mode and configuration for most of the applications. And what happens, what are the downsides? If the zone goes down, so does your application. Your application, your messenger becomes unavailable. Your users will be disappointed, at least disappointed. Some of them will never return. If the outage takes a lot of time to recover from other downsides that you can, or roadblocks that you can experience later. Let's say that initially this application messenger was designed for your north american market and their startup founders told you, hey, no worries, we're just going to build and break and disrupt. But let's do this incrementally. Let's kind of build this application and deploy it and test it with our north american users. But then what happens in, let's say, in half a year, the plans are changed and you suddenly have to expand this application to Europe. How are you going to comply with the local data residency requirements? How much effort and time should you put in redesigning your architecture? Okay, so that's the problem with single zone applications and data layers. And final one is user experience. Again, the same application. But then let's say in a year and a half you decided to expand to asian market, to Japan, to Singapore, to India. And you want those users from those locations to have the same level of experience, the same speed and the same scale. But if those users from Japan or India needs to send the applications need to send requests to your data center in Europe or in America, then the experience will not be the same, it will be poor. So that's what geodistributed applications are dealing with. And when it comes to geodistributed apps, there are two primary deployment modes, right? When we are talking about geodistributed apps, they have to be resilient and withstand various cloud outages. They have to be performant even if you deploy them across multiple zones or regions. And they have to comply with data residency requirements if necessary. So let's quickly review multi zones type of deployment because the multiregion one we will review in detail while designing the slack like corporate messenger. So on this picture, we have the same messenger application, but right now it's deployed within the same regions, but across multiple availability zones. You have, let's say instances and data layer in zone one, zone two and zone three. So what are the advantages and disadvantages? So from the resilience system point, such architecture is much better than a single zone deployment. Because if any of these zones goes down, the other zones alive and you are happy, right? And your customers and users are happy. So this configuration can withstand tolerate zones, level outages from the performance standpoint remember if to speak for the Google cloud platform, a round trip is under five milliseconds. So the communication, if you have the data layer here, the communication, you need to replicate changes. You need to keep copy for the same message across multiple zones. It's fast. It's like extremely fast from the data residency requirements. The thing is not the trivial. I mean, it depends on where your region is. If your region is in North America and then in half a year you need to expand your messenger to Europe, then it's going to be a little bit complicated because this solution is in North America. But you need to keep data of your european users in the european data centers. That's where the multi region deployments come into play. With multi region deployments, from the resilience system point, you can tolerate region level outages. If let's say your US west coast region is completely down, then your users can be directed and read and write messages to, let's say Midwest regions. From that performance point, as long as your deployment deployment spans multiple regions, on average, the performance will be lower if you compare to multizone deployments and latencies will be higher. But with multiregion deployments, there are multiple deployment options and we are going to review those a little bit later. Just fasten your seatbelts and wait. So it's not that standard. And from the data residency requirement, we are good. I mean, if you deploy across multiple regions, if one day you need to scale to Europe or to Asia, you can easily do that, right? So now let's architect that slack like corporate messenger to remind you most likely, I believe that most of you have heard about Slack or use this messenger daily. With that messenger, your company, your employer, creates a workspace, you create channels and you communicate and chat and talk with your colleagues. Also, like many communities, open source communities or other communities use slack for conversation between their members. And Slack, believe me or not, actually is A-J-O distributed application. So if you check this engineering block by the Slack team, you'll see how their story eventually they started, let's say standard application with MySqL, but then they scaled, they turned their architecture into a geodistributed one. In our case, we are not going to replicate like we are going to use other components. But at least let's review when we will be architecting our messenger. We are going to look at several microservices. So like our application, our messenger will be comprised of four microservices. The first one is the messaging one, the primary one. It allows our users to exchange messages in channels within workspaces. Across workspaces we have the profile that keeps your data, such as email, name, age, et cetera, whatever you think is reasonable to share. Also, we have two utility microservices reminders and the status one with the reminders microservice, you can ask the messenger to remind about any discussion a little bit later. For instance, right now you're extremely busy, you're doing something and you want to return to this conversation, let's say next week. And you can use a special service, you can use reminders for that. With the status microservice, your colleagues can see what are you busy with, whether you are available or not. So generally, if you're on vacation, you can change the status to vacationing. If you are in a meeting, the status can be in the meeting. Simple. And when it comes to the architecture, we need to review and consider and talk about all the components. We are going to talk about the data layer that needs to deploy and span across multiple regions. It needs to be highly available, comply with local data residency requirements, and remain high performance. Right then we will have the application there. These four microservices need to deploy their instances across the globe so that the requests from users from Europe, Asia and America are processed the fastest way possible. And finally, the cloud cloud balancer. That's a special service that is provided by major cloud vendors that captures traffic from your users and redirects the traffic in those queries to their microservice instances into the database instances closest to the user's location. Okay, let's move forward. Let's talk about the data layer. In our case, for the data layer, we are going to use Yugabyte DB, which is a distributed postgres compliance SQL database. Our messaging, our corporate messenger is a transactional application. We cannot afford losing any message. We cannot allow ourselves to any inconsistencies. But we have to be global. That's why we selected Yugabyte. Yugabyte consists of two primary components. The first one is the pluggable query layer, and presently the query layer supports SQL. Yugabyte picks the postgres dialect of SQL, and also those of you who use Cassandra. You can find Cassandra APIs handy. Under the pluggable query layer, we have the storage layer. That's the layer that is different from what vanilla postgres has. That's where your data is located. Your data will be sharded and partitioned automatically for you across your zones and regions. Your requests will be load balanced and also all the changes all the messages that you're going to send to your microservices will be transactional regardless of how far the nodes of your database are located. Speaking about the compatibility level of how what it is. So generally speaking, Yugabyte DB reuses postgres source code Yugabyte query layer uses the writer, planner executed and optimizer of postgres. It's basically the same postgres, but with several components that are enhanced so that they can interact and take advantage of their underlying distributed storage layer. So for instance, we enhance the planner, executor and optimizer so that whenever you execute your SQL queries across a Yugabyte DB cluster, the planner and optimizer can come up with the best execution plan and the executor can send this execution plan to your distributed cluster properly. Okay, so to repeat, our geodistributed messenger will spread across multiple regions. And this time let's talk about the messaging and profile microservices. Those are the key microservices of our application. They are mission critical for the success of our application. They will be experiencing thousands of requests per second. They have to remain highly available events if regions go down. Because if your microservice is not available, if your messaging service is not available, then the impact and reputation and business of our company will be in danger. Also, when it comes to the data residency requirements, the messages and profile data of our users have to reside in their locations of the locations where they live. If for instance, we have users from european region, we have to comply with the JDPR requirements and the data of those folks have to be located in european cloud regions. So what happens? What do we do? From the architectural standpoint, those are requirements. We are going to deploy a single cluster of yugabyte that spans multiple continents. But there is one important note. In this cluster, there will be a group of nodes that keep data from specific geographic applications. So a group of nodes from Europe will keep messages and profiles for the european citizens. And there will be a group of zones who keep data and messages for the asian customers. Which means that whenever you have, everything will be distributed and executed for us transparently. We just need to deploy this geodistributed cluster. The data will be partitioned based on the value of the country column. If the country column is set to UK, France, Italy or Germany, then these messages will reside and will be kept in our european nodes. And that's done for you. We just need to configure this database. We need to create these tables and we need to specify and say that the country is our partitioning column. When it comes to the performance, when it comes to the latency, it's obvious that if you have users from Europe and all those users work from company that is based in Europe, all the messages and all the data will be here locally. So that whenever you insert messages, whenever you share messages, or do like perform any other tasks, the performance will be high. The latency will be low because the users from Europe will be interacting and reading and writing data to the european nodes of Yugabyte. And the same is true for North America. Colleagues, let's say that you have people in North America. You need to send messages. You need to send and read and write channels from your database. You will be communicating to your north american group of nodes. Excellent. Another type of multi regions database deployment. It is when we deploy a primary cluster in one geographic location and in other distant geographic locations, we configure read replicas. We are going to use this deployment mode of Yugabyte for the reminders microservice. Again with the reminders microservice, we can ask the messenger to remind us about any specific conversation in an hour, next day, or any week. And generally what happens here. All the reminders, whenever someone will be creating a reminder, this write operation will be handled in the primary cluster. So if you have, let's say, a user who lives in South Korea and this guy schedules a reminder, this reminder will be written automatically forwarded from the read replica in this location to the primary cluster in North America. But whenever you are going to read any data from this local read replicas, such as in Europe and Asia, the data will be retrieved extremely fast using the local data, and this data will be synchronously replicated from the primary cluster to the read replicas. For instance, we are expecting batch reads. It's when in every location, close to every read replica, we will have a special walker that's a process that wakes up every minute, connects to the database, and pulls all the reminders that have just expired. And it will be doing this only for the local data. So in Asia, we will have a special worker that will connect to the replica, read all this data in bulk, and then we'll notify those users whose reminders have just expired within the last minute. So that's how you can minimize network traffic from the primary cluster to the distant locations if you need to read a lot of the data. And another, the third final multiregion deployment mode for our data layer for our database is when we are deploying multiple standalone databases in every distant location, and if necessary, we can synchronize those databases using can asynchronous protocol. In our case, with our messenger, we are going to use this deployment mode for the data layer when it comes to the status microservice. Again, if you're on vacation, you want your colleagues to know about that. If you are in a meeting also, you want to change your status respectively. Or if you are active and ready to chat, your status also will be set to active. And in this case, we decided, all right, we do expect that we still have high availability, right? But we're not expecting that the status will be changed, let's say thousands of times a second. It will happen, but it will happen. Not that requests. At the same time, when my colleague connects to the opens my messenger, he wants to see statuses of all the colleagues. So, like, I want to have fast reads, but when it comes to writes, I don't care. And also, asynchronous replication is suitable here. For instance, let's say that someone who lives in Europe went to a meeting and his status is changed accordingly. This information will be written to the European data Center, because that's where this user resides. But then this information, if necessary, can be replicated to North America and to APAC. The replication can take, let's say like few seconds, like 510, and depends on how fast the connectivity between these users. But generally it's not a big deal. Let's say if a teammate of this guy who lives in North America will see his colleague from Europe start to channels in five or 10 seconds, right? It's not a big deal. So that's why it's totally fine to use the asynchronous applications between these distant clusters. That's why we selected this for the status microservice. Okay, to conclude, that's it for the data layer component of our geodistributed application for this. As I said, when it come, there are two primary deployment modes. You have a multizone deployment for your data layer, or you have multiregion. Multizone is easy, but with multiregion, we also have three options. We can deploy a single geodistributed cluster, and every data will be pinned automatically based on the value of your partitioning column, such as the country one. We use it for our mission critical microservices, messaging and the profile one. Also, the other deployment mode for the multiregion databases is the primary cluster with read replicas in distant location. We use that for the reminders. Keep this in your toolbox as well. And the final one when you don't actually care about, let's say, if you allow, let's say, distant locations, read stale data that will be synchronized later. Then you can use multiple standalone clusters in every location and then set up bi directional or unidirectional replication between them. It's enough for the data layer. Let's talk about the application layer when it comes to the application. Again, we have four microservices, messaging, profile, reminders and status, and we have customers across the globe. We are going to deploy an instance of every microservice in every location in North America, Europe and Asia. Also, we are going to allocate those instances with the local yugabyte nodes. For instance, if my Yugabyte DB zones are deployed in the London data center cloud region, then I want the instance of the microservice for the messaging and for the reminders to be located in the same region. Why? So that the latency, the performance remember if, even if to take Google compute platform as an example, the latency between the availability zones within the same regions is under five milliseconds, which is excellent. So like whenever our messaging microservice instance receives a request to write or read the message from a european customer, it will get it and it will instantaneously request or write data to or from the database fast, right? It's calculated. So here is what technology to use. How exactly do you deploy your microservice instances? It's up to you. You can use, let's say app engine of Google Cloud platform or a similar service in AWS or Microsoft Azure. Or you can deploy everything in Kubernetes. It's highly likely that Kubernetes like containers and Kubernetes as an orchestration layer are the best option here. But anyway, we will leave this question and answer it's up to you, literally whatever is more preferable for your architecture. It's just that you need to deploy those instances across various locations. Same for the communication and the connectivity layers and patterns between your different microservices. It's true that the messaging microservice needs to read profiles from the profile microservices. The reminders microservices need to kind of pin the reminders to a specific message and it will communicate the message in microservices. So here is again, I'll give you flexibility. Use a communication pattern that works best for your deployment. You can use message brokers to communicate between microservices. GrPC like sidecar or whatever is more applicable. Okay, data layer, application layer, and finally we have the cloud cloud balancer because right now we have a global architecture, we have database zones, we have microservice instances across various continents, but we want this back end and data layer to be as simple as possible for our front end, for our end users. That's why my suggestion would be to have a look and benefit from the global cloud load balancers. It's usually like every major cloud provider has them. So what's the purpose of their global load balancers? Load balancer provides you with any cast IP address, that's a single external IP address that can be used by your front end applications and your mobile applications, and when someone, let's say, connects to your front end. Depending on the location of this user, the global cloud balancer will send this request to the closest microservices and to the closest database nodes that are located close to this user. Let's take an example. Let's say that we have a user who is based off Europe and this user opens up your messaging application on iPhone, iPhone, uses this anycast ip address and connects to the global load balancer. The user refreshes a discussion in one of the channels and you want to read all the messages from this channel. So the global load balancer received this request. It sees that, okay, the request comes from a person in Europe. So then we have an instance of our microservice in Europe. Let's forward this request there. This microservice instance received this request and it's already connected to our geodistributed database and it will send this request to our local database nodes. Easy right? So that's how you can take advantage of the global cloud load balancers. Also, this load balancer is fault tolerant. Basically it supports automatic failover in case of outages. If, let's say, your data center or instance of your microservice is down here due to different zone or region level outages, the global cloud balancer can redirect the user's traffic to the other nearby location to the other nearby instance. It's all done for you. Wonderful. So as a summary, geodistributed applications are becoming a new norma, new normal when we are building cloud native applications, because usually the user base for our applications is global. Even if you're planning that your application is going to be used primarily in North America or in Asia, it's highly likely that on some day, if you become successful, then you will become the victim of your own success. You will get a global user base. And it matters a lot what was the foundation of your architecture, even if the first version of your application was deploying your messenger application and your database within a single region across multiple zones. But if it can scale to other regions and to other locations easily, then you are in a win win situation. So right now you're using the resources that you need. But let's say in a month or like in a week, you need to expand to Europe. You just spans your database across, let's say North America, in Europe, or use let's say any other multi region deployment mode that we discussed. So that's why think globally when you're building new cloud native applications and have a look and consider the different design and consideration patterns when you're building geodistributed applications. If you want to learn more, my advice would be to check these two books by Orali architecting for scale in designing data intensive applications. They give us more details on how to design highly available and high performance distributed applications, and that resonates really well with the topic of today with the geodistributed apps. Also, if you are curious about the data layer component, about the yugabyte, how it works, how to deploy it, and how those multi region deployment mode works, just my suggestion would be go and complete one of our free courses. That's the easiest way to get to know our database data and this corporate messenger flag. Like corporate messenger, we have a gitpod sandbox environment. Go to this GitHub project and you can run this in your Gitpad workspace. So right now we support as of time of this recording, you would be able to start to deploy your various you would be able to deploy Yugo by DB in various configuration modes for multiregion deployment like geode distributed primary cluster with red replica, et cetera. And then over the time we are planning to improve this sandbox, we are going to add the front end and the back end, et cetera. So you can subscribe and watch to the changes. If you have any other questions, you can always find tag me and send me a message on Twitter. Or if you are particularly interested in Yugabyte DB then join our communication like community. And the easiest way to experiment with Yugabyte is by using our cloud product. Thanks for joining, thanks for watching and enjoy the rest of the conference.