 Hello, this is Brian Wild solutions architect at GitLab. Today, I'm going to give a overview of high availability and geo-replication inside your GitLab instance. First, let's take a look at some of the advantages and reasons to set up high availability and GitLab geo-replication. There are three main reasons for this. The first is the responsiveness and performance of your development team, even at peak load. If the demand increases, you have to control the scale out those resources on the fly. Additionally, HA and geo are important for geographically dispersed teams, as you can lower the latency and increase speeds by creating secondary instance closer in proximity to the other parts of your development team. Next is to prevent downtime. Reducing the load by breaking out heavily used services into separate nodes will prevent the tasks from building up and the potential for your application to go down. Additionally, HA allows you to run update upgrades without any downtime for your development team at all. GitLab releases new features, bug fixes, and security patches on a monthly basis, so keeping up to speed with that and utilizing these updates is important to use an HA setup so that you don't have downtime for your development team. The last is risk mitigation. Setting up HA and geo replication, which I'll go more into detail in this presentation, will provide a simple and quick mechanism to fail over to a secondary redundant instance in the event that your primary instance goes down. This also inherently provides a disaster recovery by syncing all the backup of your data to the redundant instance. So you always have your data in your application running in more than one place at a time. In addition to the three main reasons why you would use HA, I've also identified a couple of key indicators that will help you determine if HA is the right setup for you. Essentially, if you are utilizing GitLab for mission critical applications, if your team is scaling, or if you're hosting large or sensitive data, it's a pretty good idea to utilize HA for your setup whether you're hosted on the Cloud or on-prem. Now, earlier I mentioned scaling high resource services to prevent issues under load. This slide gives you a look under the hood of GitLab's modular setup and the discrete services that are commonly scaled in an HA setup. For example, if you make heavy use of the API or cloning large repositories often, you may want to break out the sidekick job service to a dedicated node. We have categorized the different architectural approaches into three models based on the demanded complexity. As the demand and availability needs increase, the architecture becomes more robust, but so does the complexity. The horizontal model is a common HA setup as it's the least complex. It's great for small to medium-size demand and relatively easy to scale out. As you can see in this example here, we've got a pair of load balancers that feed into two or more application servers. That's two or more Redis, Postgres, and console nodes. As your demand increases, a hybrid model allows for a similar architecture to the horizontal one we just saw, but it breaks out high load components into their own nodes. As you can see in this example here, it's the same as the horizontal one, except we have the sidekick, which is the background job service, split out into its own dedicated node. It's important for preventing bottlenecks that may get built up in this particular task. And the last example is the distributed model. This takes the hybrid model further and breaks out all of the services that were previously sharing resources on the same node into their own discrete nodes. This architecture is the most complex to setup, maintain and monitor, but allows for very heavy demand and more precise scaling control. To get idea of the scaling capabilities, this model is what's utilized for GitLab.com to host all of the projects running in the SaaS offering. As you can see in this example, sidekick has broken out to multiple nodes, the traffic's been split out from Git API and web traffic, and there's more database caching and redundancy. Now that you understand the basics of setting up an HA environment, the last component for creating a robust GitLab instance is to utilize the geo-replication service. Geo allows you to have multiple secondary GitLab instances geographically located close to your distributed team for faster read times. In addition to performance, provides a convenient failover in the event that the primary instance goes down. And since it's a synced replica from primary, it also acts as a backup for disaster recovery. So you can find robust documentation on GitLab.com by clicking one of these links here at the bottom of the screen. But in addition, if you need help, GitLab also provides professional services to support your organization, everything from auditing and architectural recommendations to building out the HA setup and providing training and workshops for your team. Down the road, our support team can also help in the event that something happens to your setup or you need assistance if something worked to go wrong. Hope you understand a little bit more about HA setup and thank you for joining.