GitLab Customer Success Group, 28 May 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Sales Level Up - Reference Architectures

Description

A quick overview of GitLab Reference Architectures.

Learn more about Reference Architectures: https://docs.gitlab.com/ee/administration/reference_architectures/

A

Hello, everyone and welcome to another session of the sales level up series. My name is Ken McKnight and I'm, a Solutions Architect here at get lab and today we'll be covering reference architectures. So before we start, let's go over a few terms here that will you'll hear several times during the presentation, so the first is AJ or high availability.

A

The second is geo and the third is RPS, which is requests per second all right. So how do you respond when your customer says something like this? So I've got this 4500 users across three sites and I definitely want my system to be highly available and have great performance for all my teams that all my locations can you tell me how many hosts I will need to support this architecture.

A

So a great question right and here's how we're going to answer that? First, we're going to review the gitlab architecture and then we're going to identify which reference architecture makes the most sense and the three requirements we're going to look at mainly are user count, h.a or high availability and whether they need Gio and then, lastly, we're going to drill down to view the specific configuration okay. So, let's start with a simplified component overview. This is basically what the gate lab server application architecture looks like.

A

It has eight or nine components, and it's good to review this with the customer, so they get a general overview of what's going on now. If they ask more detailed questions, you can simply scroll down to the component diagram. This adds a lot more detail to the connectivity between all the pieces. You can see all the different ports that connect it and all the different components at a much more detailed level, now so say, for instance, that they're curious about a particular a particular component.

A

So what we can do, let's say, for instance, we want to look at Prometheus all right, so what does Prometheus do and how does it fit in? Well, if you look on the right side here in this menu, you can see details and if we look down there we are, we have Prometheus a link to it.

A

So if we go over to that link, then we can see the project page for Prometheus how its configured, what layer it's in and more details can be found at the website, but this basically tells us what Prometheus is and it's basically a way to help admins expose metrics within their system, so perfect. It helps us with and- and you can see that on the right there, every single component is described.

A

So that's how you can get that extra information all right so now that we've gone over briefly, where you can discuss with your customer the overall architecture of git lab, as well as the detailed bits for each component. Let's talk about reference architecture, so why do we need this?

A

Well so git lab server can be scaled up to handle many users and, as this chart shows, you can see that we can start basically down here near the bottom at zero, and then we have reference architectures that hit a thousand users, three thousand five thousand ten thousand twenty five thousand and fifty thousand, and the reason why we do this is to provide the configurations they make the most sense for our customers.

A

How did we get all this information? Well, we act. The quality team actually wrote a a performance tool right here and you can click into it's open source and we'll discuss it a little further in a blog post that I'd like to to point out, but for now I'm just know that we have a performance tool and that's how we're able to get these numbers.

A

If you recall, we talked about requests per second, and so every endpoint every place that we want to test has some metrics behind it, and so you'll see that as we look at the different configurations now, if you recall our customer had asked us about 4,500 users. So, let's take a look here here are the reference architectures, so forty five hundred users falls somewhere between 3,000 and 5,000. Let's assume that we want to have a little bit of room to be able to expand from 4,500 to possibly 5,000. So let's select that one alrighty.

A

So now, when we drop into this page here we get a wonderful table that completely describes all the different services, how many nodes they need and what kind of configuration the administrator for the customer might want to consider. So these would be hardware configurations, for instance, and then, if they're interested in cloud, they can look at GCP, AWS and azure and which kinds of machine types or instance types would match the configurations listed here. Now you also note at the top.

A

Not only does it highlight that it's a supported user base of about 5,000, it also mentions a chae or high availability is true and it talks about the test rates so that your customer can understand exactly how we tested against this and last but not least, you'll notice that most of the services have footnotes and if you scroll down, you can see the footnotes describe additional comments, either recommendations or caveats about those particular items that make sense for them and that's basically it as so: let's, oh yeah, so that's it for the reference architecture.

A

Remember I talked about the performance tool, so we've got a really great blog here, written by one of I, believe the quality engineers grant young and it talks about leveraging this performance tool. So you know one of the initiatives that we had was to test and improve the performance of gitlab. We needed a way to do this, and this is how we came up with the gitlab performance tool or or GPT.

A

We run it and we use it extensively for the reference architecture.

A

These are this a little more about what it is, how we use it, how you can get it, meaning how the customer can get it, so the customer can actually download this and run it themselves on their own on their own systems, to either test out that what they currently have is good or the architecture they're going to put in place make sense, there's a video here which is really great to see how it's run and then, let's talk a little bit about the future right.

A

What's next so clearly, the quality team is always aiming at making get labs performance the best in class, and so they are continuing to work on the test tool, and that includes links here. You can see to the next really releases and what they're gonna add to expanding the test coverage and making sure that it's the best it can be ok.

A

So, in summary, this is how we answer the customers question. We reviewed the gate lab architecture, both the overall in the details we identified the appropriate reference architecture and I came up with a little acronym hug, so H a user count and Geo.

A

Those are three things you main three things you need to capture from the customer so that you can decide which reference architecture makes the most sense to present to them, and then, last but not least, we drill down to view the specific configuration I also wanted to show you that I included references here. So all the pages we talked about are on our website, we're big fans of website first and single source, so everything I talked about is is on the website based on these links, so.

A

I want to say for attending this sales level up session for gitlab I'm, Ken McKnight.