GitLab Tanuki Tech, 4 Feb 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: TT300: Advanced Sales Conversations

Description

This is a Tanuki Tech session on 2/4/2021.

For more on Tanuki Tech, see here: https://about.gitlab.com/handbook/marketing/revenue-marketing/sdr/tanuki-tech/

For more on the speaker, see here: https://www.linkedin.com/in/christopher-wang-0835b226/

A

All right, so today's session is about advanced sales conversations and really what we're talking about is, and a lot of the sales calls that we're on the people that we're talking about are asking for things like tell me about how you're migrating the cloud tell me about how you're making your organization more efficient. So, ultimately, these are the strategic drivers for many of our customers, businesses and we're going to talk about how we can insert ourselves into these some of these conversations and ultimately drive value.

A

So specifically, what we're talking about is talking about the largest technology trends today and how to leverage these within our conversations and, ultimately, the difference between pitching products and solutions. So have you heard of the difference between product sales versus solution selling?

A

I have okay cool, so just go over that real quick, then.

A

So, when you sell products at a very high level, people are asking things like hey: can it do this? Can it do this? Oh this one is one dollar or more. Well, basically, it's a conversation about functionality and price right contrast that with selling solutions and then all of a sudden, you have now multi-year commitments that are a much higher dollar value.

A

So, if you think about the difference between selling like a gym membership versus selling like a health and wellness system which would include training, your gym membership, also videos also like dietary stuff, that you get shipped to your door.

A

So what the research has found is that, in our current time, solution selling is way more effective for complicated customer problems, and the reason why this is good for us is because technology in general is very complicated. It's not really so much about like hey we're. Looking for one tool, can it do this? Can it do this? It's talking about? How can I pivot my business so that I can have strategic advantages over my competitors?

A

The reason why all this stuff matters is because all of the technological things that businesses are investing in, they basically play into this right. So the reason why businesses are migrating in the cloud while they're investing in microservices and doing all this other stuff is because they're trying to solve extremely complicated problems that will ultimately give them advantages.

A

So at a high level, again product sales, it's about capabilities and price. That's basically transactional a lot of times. You're gonna have to offer discounts versus solution sales. It's usually a multi-year deal. It's usually something much more complicated and once again the research shows that for complicated customer problems, it's way more effective.

A

So let's talk about the general methodology for solution selling. This is something that we hear a lot of the times on our sales calls. But the first thing is uncovering problems by asking questions, so I'm sure that you've heard what are some of the current initiatives in your organization. That's a really common one, but then ultimately presenting solutions and discussing proof points so pivoting from here's.

A

What you're trying to do to hear how we can help here's, how gitlab can be a strategic partner for you to help you solve your long-term initiatives and now, all of a sudden, you have a three to five year deal. Maybe it's ultimate probably includes professional services and implementation so versus. If we get pivoted into a product sale. It's just. Can we do this? Oh github. Does this give me a discount right? So that's the big difference.

A

So what are some of the current problems that we have for business executives right now, there's a bunch that are specific to an industry, but in general across like the developed world right now, what we see is really five main issues. One is how to keep up with latest trends.

A

Technology is always increasing, so how can we make sure that we have the latest and greatest stuff, which is a strategic driver for my business right? If my business is doing something, if my competitor is doing something more efficiently than me, then over a three year time horizon that's going to be a competitive advantage for them problem number two is: how can we keep on deliver quality software on time? This is something that all businesses care about, while at the same time reducing cyber security risk and maintaining compliance.

A

The last two ones is: how do we develop and retain talent, and how can we make sure that costs are reasonable? So these are general business things, but when we are on these conversations and customers tell us hey we're migrating the cloud: hey we're investing in microservices and some of these other technological things. It's really important to understand that these tech changes that they are doing they just fit into the larger business goals that they have so the largest four technological initiatives that we have currently right now in the year.

A

2021 is one adopting a cloud strategy cloud migrations. Basically, every single business that you talk to is thinking about already has migrated things in the cloud number two is: how do we adopt automation, best practices? Ultimately, what this allows people to do is save time money energy and allows them to basically become more efficient.

A

Number three is adopting infrastructures code, we'll talk about what git ops is, um but I'm sure that you've heard around explain exactly why people are trying to investigate things like infrastructure as code and what git ops brings the table and the fourth one is really really big. This is one that is going to be a strategic driver for many businesses and save many businesses, maybe 20 to 30 in cost is adopting containers or microservices across all of their applications. So we're talking about reducing your operational expenses by significant margin.

A

So some of the questions that um you know you've heard in a lot of your calls is what initiatives do you have planned for your organization? What is your current cloud strategy so on and so forth? um How often do these things come up in your current calls.

B

Almost I would say every call yeah yeah, it's it's like that. One of the first or second questions the sal is always going in on.

A

Yeah exactly what are some of the ones that you've seen most effective in terms of pitching to get lab value.

B

um I do feel like initiatives is one of the more effective ones, because it you know, there's initiatives regardless of level like someone who is a individual contributor also has initiatives, as does someone who's a c-suite, um so that one sort of hits hits on each person. Something like cloud strategy isn't necessarily a question. You can ask everyone, because someone who's a lower level like engineer, isn't really gonna care or know yeah. That type of information so yeah, I feel like initiatives, is so broad that it like captures a lot of people.

A

Yeah, I think that the big thing that we can do here is to find out what they're trying to do and ultimately to show how gitlab can solve their problems and then all of a sudden, as opposed to a conversation about well jira. Does this: do you do this? Now we can talk about how we can be a long-term partner, allowing them to drive strategic value.

A

All right, so, let's dive into how gitlab can help so the the number one big transition that businesses are facing from a tech perspective is cloud migrations. This is something that I was talking to one of my counterparts who used to work for aws, and it was really not uncommon that their sales team there would sign multi-billion dollar deals. So we're talking about the two to three billion dollar deal range.

A

It was something that happened every week for them and the reason why so much money is coming into cloud is because it really is strategically changing how tech works in our space.

A

So before we dive into cloud, it's really important to just do a brief review and talking about the fact that 20 years ago you had all of your own servers. If you wanted to expand out your website, you bought more servers and the big problem with that is now it's a long.

A

It's a long process to get all of this upgraded right. So it's maybe a hundred thousand dollar investment. It goes through procurement. All the hard work shows up at your data center.

A

Then your engineers, they basically spend maybe a month racking all the servers installing your stuff on it, finally putting it into production and contrast that, with um what we have today, where we have these large public data centers, where you can just rent a server from anywhere in this data center, so as opposed to having to go through procurement, signing a bunch of papers having to select a vendor doing it all yourself. I can now pay someone 12 cents per hour to rent one of their servers in some combined shared facility.

A

That, ultimately, is what all these large public clouds are doing and while we're, where we see the industry moving right now, is to hybrid cloud environments with multi-cloud deployments. Let me talk about what this means.

A

People want to be on multiple public clouds, because they're afraid of if we put a hundred percent of all of our stuff on one of them, if they basically jack up prices, then we're locked into this one major public cloud so um for large banks and for especially in the enterprise space.

A

What you'll typically see is that maybe 70 of all their stuff would be in aws, 20 would be on azure, and maybe some of their developmental stuff would be on a gcp, but they do that on purpose, to spread it out among multiple different clouds and from a business strategy perspective, um so businesses around the world what they're doing is, as opposed to investing in all of their own infrastructure. What they're doing is they're just moving all of those workloads into the public cloud. This is something that I'd say.

A

Probably 50 percent of customers are actively doing right now. That being said, some workloads have to run on-prem. So when your customer calls, what are some of the reasons that customers have given you as to why they need to keep something like gitlab, on-prem.

B

uh Security is like the number one like concern over security from data privacy if it's like a healthcare institute or government agencies, those are some of the reasons.

A

Absolutely one thing to note about this is that that's going to decrease in time, because the u.s public government just signed over 10 billion dollar deal with microsoft, azure, and so the us government signaled in that is that we trust microsoft so much with our most important defense workloads.

A

I think that other people are going to start following suit as well. Okay, so the other reason why people are moving to the public cloud is for this thing called auto scale. Is that something that has come up in your conversations? A bit.

B

No, I actually just wrote down that as a question. I've never never heard of that.

A

Okay, we'll talk about what that means, and let's talk about how one this is accelerating and to just like dive into a little bit more about what this is about.

A

So we basically talked a little bit about how before. If my business wanted to expand our server fleet, you have to go select a vendor. You have to go through procurement. Procurements basically has to sign a bunch of paperwork. Finally, your hardware comes down. Now you basically need to get your own engineers to rack it and then finally install your applications on that. The problem with that is that might take three to four months in today's world. That's too slow!

A

If someone can basically go on the internet and get more servers, then they're going to basically be able to move faster than you, it's going to be a strategic driver of their business, and so I just want to show a little bit about how fast this really is. So this is my aws account if I'm going to go into the launch instance page. What I see over here is what type of server do you want if you want linux server? That's fine if you want mac os, that's fine!

A

So let's just pick red hat, then how like how much hardware do you want in this server? All of these different servers have different configurations and you actually have to call pay more money if you want more hardware, so some of these are about 8 cents per hour. The most expensive ones are around 50 cents per hour that I've seen.

A

So, let's just select something right over here.

A

Let's just say I want to scale up real quick. I want 100 new servers.

A

So over here is basically some configuration stuff, and if I hit this launch button right here, then within three minutes I would have 100 new servers that I can now load up into my fleet, so the business that can do this is going to be able to move faster. That's part of the reason why people are moving in the cloud.

B

Pretty similar like across vendors, like is it that easy on each of them, or is that just something that's relevant to aws.

A

Yeah, so all of the public cloud vendors there and part of their strategy is they want to have the most streamlined and easy to understand, um purchase experience, because if it's too complicated, they lose sales right.

A

So every single one that I've used, they're pretty simple in general and the whole goal is to make it as simple as possible.

A

All right, so, let's talk about two of the other strategic drivers for the cloud. So number one is, I don't want to say, cost savings, but it's part of it.

A

But let's just say that you are your walmart right and the x-axis over here is what time the year it is so january february, june july november december, and then the y-axis here is the amount of servers that you need. So during january and february, there's a lot of people at home, so they're buying a lot of stuff, but once the summer hits people are going outside, but then back to school hits there's a huge spike around august and then towards christmas. There's a huge spike over here too.

A

So the big problem is that if you had all of your own servers, then you need to get capacity for this level there. They know that traditionally they have this amount of load that they need for the holiday months and they need to build in some buffer in case their projections are wrong. So this is maybe an extra 20 buffer.

A

The big problem, however, is that all of this area over here is wasted in idle capacity, so this is servers that are sitting around in your data center, not doing anything that could basically it's basically cost that you're not utilizing at all, so what businesses can do now is they can get more intelligent with it and say: let's get this amount of capacity, this amount of capacity is going to be in our own internal data centers for the rest, for only this time of the year, this time of the year and this time of the year, let's rent from a public cloud, ultimately allowing us to save money.

A

So that's what we call the holiday demands problem, the other um can I help clarify anything about this chart. I'm going to move into the other strategic driver for cloud.

B

Makes sense that's this is a really great graph. I didn't know that something that companies do yeah yeah really for sure. What did you say was.

A

It's called the holiday demands problem.

A

Okay, so the other reason why people are moving the cloud is for what we call elasticity.

A

And from a technical perspective, the engineers will call it auto scale.

A

So what we're talking about here is, if I'm designing an application on the public cloud, then I can make it so that it is smart enough where, if more people are visiting our website, more people are visiting our website.

A

It's smart enough to basically talk to the public cloud on its own and get more servers um completely on its own and then once 1am 2am hits where no one's visiting my website anymore. It will actually scale down on its own without any human intervention, so you're, basically paying for exactly what you use I'll. Give you an example of this. This is a nike flash sale. So let's just say that this is noon time.

A

This is midnight.

A

What a nike flash sale is as they do this thing for, like jordan, brand shoes, it's basically a sale for, let's just say, like 10 000 of this really rare model of jordan brand shoes at like a really nice price point, and then so. Here's our web track effect for nike, so no one's visiting it in the morning. People are checking it at lunch.

A

People find out about the flash sale on reddit and in social media, and then the flash sale is at 8 pm and then it basically just skyrockets and then it runs at a capacity. So they run out of inventory and then people are disappointed for like the next couple of hours before social media says that it's out and then it goes back to normal.

A

So when you design an application to auto scale, it's smart enough so that when all of your workloads are running in the public cloud, you're only paying for what you need, it's smart enough so that your application senses hey a lot of people are hitting up my website right now, let's scale up in aws and then once people start you know, demand starts going down. It starts scaling down completely by itself.

A

If you have an application that has auto scale implemented, then you don't need some sort of engineer in the background going around and then switching stuff around. That's the big advantage. So now just think about this from a business perspective, if you're a business that doesn't have this, then your engine, your website's, going to become super super super laggy until your engineer can basically keep up with demand. If it's done in an automated fashion, then it's going to be a better streamlined experience for your customers.

B

So is autoscale a something that you pay for like with one of these cloud providers, or is it something that your like engineering team has to enable themselves.

A

It's a combination of so the public clouds want to make their service the best and they want all of the workloads. So aws says: auto scale capability is free, so basically the idea is that we have to have the best auto scale offering. Therefore we can get the workloads and therefore people are paying for our cloud servers. Now we have all the workloads.

A

So what I've seen in general is that auto skill capabilities is free, but if you really want to take it to the next level, then it's going to be a combination of the built-in auto skill capabilities in the public cloud. In addition to logic in your applications themselves, once you have some sort of layer where your applications has implemented auto scale and the cloud vendor knows how to auto scale on its own. That's when you have like a home run solution.

B

That makes sense. Thank you.

A

For sure all right, so let's talk about some of the cloud benefits and challenges so one you can move faster, a business that has the public cloud can basically scale up.

A

um Let's just say they can in our day and age, especially in the tech industry, like your ability to basically update your website quickly, that's going to be huge, especially if you're, a or b round company, so it's especially important for small medium businesses, application skill or elasticity so paying for exactly what you're using and then also the fact that you can basically have a more robust web service. So if you think about something like netflix, netflix has to remain very, very, very streamlined and performing.

A

If netflix is really laggy, then their customers are going to go to youtube or hulu, or something like that, and so application scale is really really really important driver for many, like video and like media businesses.

A

So some of the challenges for this it's a huge shift in terms of how engineers think about this, you have to hire new people who understand the cloud who know how to architect software for the cloud. It's not just like a copy and paste type of thing. You have to basically rewrite some of your applications and the other challenge is maintaining what we call vendor agnosticism.

A

So there's this perception in the tech world right now that eventually amazon's going to crush everyone else and then they're going to price surge, which is basically like what a lot of people think is going to happen. So a lot of these businesses don't want to put themselves in a position where, if amazon actually does price surge, then they're completely 100 locked into amazon and then they're stuck with them until they can migrate off somewhere else.

A

So maintaining almost like a switzerland approach for these public clouds is what a lot of these larger enterprises want to. Do. That being said, there's usually one main public cloud and then there's usually a couple of more minor public clouds that they still want to have some workloads on.

A

So let's talk about how we can help with um public cloud deployments so review of gitlab is that people create issues on it then eventually developers they code, they submit a merge request, but what we actually do doesn't stop with rci.

A

The great thing about get lab is that we can deploy to production and regardless of wherever that production is so if it's an aws lambda, if it's in gke, if it's a microsoft azure, then we can deploy their workload to that target, and so what we actually bring the table is one we lower the barrier of entry for cloud adoption with gitlab, and so what I mean by that is just imagine someone who's starting out in cloud they're, going into the ui they're clicking launch instance.

A

Every time they want to go update, one of their websites and stuff they go and do everything to the ui that takes a bunch of time. They have some engineer who's, doing it versus, if gitlab's doing all this stuff in an automated fashion. So every single time a change comes through then gitlab, smart enough to redeploy your applications in the public cloud. So, all of a sudden that just basically just makes it so that your engineers don't have to worry about as much parts with the system.

A

The other thing is how to more efficiently utilize cloud spend by using git lab to do automated deploys right. So this is the power of automation right here.

A

Once again, let's just say your engineers are wanting to go update their website. So what they do is they go into the instances section they find out all of these ones that are old, then what they have to do is they have to kill them right.

A

So they're going to go to terminate the instance and then what they need to do is to remember that they killed three instances and then they want to go launch in a replacement three instances. All this stuff is super manual super time consuming. If someone forgets something, then it's gonna result in a really big problem for the business if everything's automated it basically just makes it so that you're more efficiently, utilizing your cloud spin and once again for these large enterprises, they're, typically spending a bank of america.

A

You know um a wells fargo they're spending north of one billion dollars on these cloud contracts, so the ability to automate this and to make it more efficient is talking about more effectively utilizing your expense, maybe 10 20 30 percent. So it's a huge difference in a value driver for these businesses.

A

Last reason is that we reduce vendor lock-in because of the fact that git lab supports all of the clouds, regardless of if you use ibm cloud gke aws gitlab has support for all of these clouds. um Yeah does vendor lock-in ever come up in any of your customer conversations.

B

Not really, I'm sure it would if it was like in the pnw um but yeah I haven't run into it. A bunch gotcha.

A

Were you surprised at the dollar figure of some of this cloud spend.

B

uh Not really because splunk just from being at splunk, they spent so much on it, and I remember when we transitioned over to aws and like I think I saw some of the dollar amounts and it was like, like over 20 a minute or something yeah so, and that was just for, like our team, which was like just over 100 people, so yeah, I guess not surprised, but it is pretty crazy.

B

A

All right so now, let's talk about adopting automation. um How often does automation come up in your conversations.

B

um Quite a bit with like um organizations that are further along, but a lot of times I feel like it is smaller orgs that are like going for automation, because a lot of these, like bigger enterprises, have all these like massive tools and they're just focused on getting on like one streamlined system instead of like automating yeah but yeah. I feel like the customers that are smaller and have an opportunity to adopt. Something like extremely earlier, are like more focused on automation, yeah for sure.

A

So um benefits a lot of this is going to be pretty straightforward. You can move faster, so we're talking about netflix who's, redeploying, like several times per day. You basically need automation. There's no way that you can do this without automation.

A

It allows you to relocate engineers to higher level tasks.

A

What I've seen in general is that all of the higher performing businesses they have a ton of automation, so a lot of their different processes completely automated other reasons why automation is good is because you're, more scalable and what I mean by that is, let's just say that you need to redeploy all of your web servers right, so that might take someone doing it by hand, maybe a couple of months, but if I have a script to do it, maybe I just need to rerun that script three times one for north america, web servers, one for european based web servers and then one for your japanese web servers right.

A

So it allows you to scale things pretty quickly from a work perspective.

A

Last reason: why is reducing human error? So every time I go do something using a ui. If someone interrupts me- and I forget something- then all of a sudden then like I could make a mistake versus like if we really have things automated down to a t, then there's just less room for error in general.

A

So in the having talked with like hundreds of customers, the last couple of years, the vast majority of them are in some place in their automation journey. They all know that they want more automation, but the big challenge is: how do they get better automation and how can they unify automation so things that I heard a lot is hey. We have a jenkins server. We have some ansible and terraform scripts, some powershell scripts. The problem is that some of them are on jenkins.

A

Some of the ansible scripts are just living in some of this other place and there's no like unified platform for automation. The big problem with that is that it basically just becomes a big jumbled mess um and especially if one company is acquiring a bunch of other companies, then we have all of our automation. They have their own automation and nothing is aligned right.

A

So some people are have really really great centralized systems for automation. Some of them don't have anything. If they don't have anything, then they say that they're doing things manually and every single person that I've ever talked to isn't happy with the fact that they're doing things manually.

A

So what we bring to the table is that we bring tons and tons and tons of automation to help your developers develop more efficiently so over here this is um just a screenshot of what gitlab does for its own internal projects.

A

But let me just talk to you about some of the time savings that this stuff is doing in this prepare stage. This might take me 30 minutes in the build images stage. This might take me maybe five minutes in the test stage. This probably takes me in general, several, maybe maybe an hour two hours.

A

So if someone were doing this by hand, it saves me maybe five to ten hours every single time, but when you're paying engineers to do this, and they only have 40 hours a week, we're talking about saving them, maybe 10 20 of everything that they do and now they can focus on something. That's more important.

A

Ultimately, what we do in terms of automation is we help you to maximize your automation with gitlab ci cd, and so what we're talking about streamlining the utilization of your automation so over here in this uh ci cd pipeline.

A

Some of these could actually be automated scripts, so over here in the deploy section, this could be your ansible script in the prepare section. This could be like a bash script, so we can actually allow you to leverage the stuff that you've already written, combine it as a universal system with git lab and now gitlab is automating, the utilization and the execution of your automation in general.

A

So, once again, gitlab can be that unifying system that automates the automation that you're already using it brings you all of this automated and some of these stages could be the stuff that you've already written.

A

And ultimately, what this allows you to do is when you have a streamlined system, you're getting more out of the stuff that you've already written. You don't have to go remember to execute your ansible script. You don't have to remember to go like execute some of the other stuff that you've written and that also reduces human error right. So in general, we're talking about all this business value for automation, ultimately, saving businesses, time money, allowing them to move more quickly.

A

What we do is we allow them to one become more efficient at their automation, utilization and two. We give you a bunch of automation right out of the get go so there's this thing called auto devops.

A

It gives you a good chunk of all this stuff automatically, so you don't have to write the job you don't have to have a bunch of engineers write something in ansible to go. Kick off all this stuff. We basically had this one team. That said, we understand that this is a common customer journey. Let's just create a path, so that using all of this stuff is super super easy. You don't have to write the job itself and that ultimately saves customers even more time.

B

Is auto devops built for complex use cases, or is it built for just like standard workflows.

A

It's built for standard workflows, not everything. There's no like one size, fits all policy for all of our customers, but it wants. We basically made it so that we wanted to have use for 80 of all of our customers.

B

Gotcha, and can you um modify it to like, can you customize in any way or does it have to be like what it is preset.

A

I'm actually not sure how customizable it is. So let me get back to you with that answer to that question thanks for asking it anything else over here uh strike out to you, or can I help uh um clarify anything here.

B

um No, I think it's it's great. I it ties in nicely to like the same values that clouds are dry, that cloud providers are driving with automation, um and so I think it's the good thing that you could tie how git lob you know also has this value of automation, how you could tie that in with your cloud provider as well yeah, I.

A

Think it clouds nicely. Yes, cloud providers want to have a lot of automation in their systems running behind the scenes, so that their platform is the easiest to use. Basically, if they can make their platform like, have the most business value and make it easiest for all these engineers who are using it, then they're going to get more workloads. Basically, so a lot of times, there's actually automation, running behind the scenes that engineers don't even know about you never see it, but that's. What's powering a lot of the public clouds behind the scenes.

B

Yeah, it's a good thing that the like automation, values, align because when like gcp and aws reps are selling their cloud services and honing in on that, I feel, like it'll, be easier to tie in gitlab because they're like hey. This is another product. That's the same value system as us that can improve you even further net levels. I feel like that, helps with that partner, sale.

A

Yeah, I completely agree.

A

All right, let's talk about infrastructure as code now, um so in the beginning we talked about how, 30 years ago, you had all of your own hardware, you racked your own hardware, some guy literally had to like plug in a bunch of cables, connect all this other stuff. You know screw a bunch of stuff in, but let's take a look at the thing in the right. What do you think that this is.

B

A

Script: yeah, but what is it doing.

B

um Creating a new server.

A

That's exactly it so over here we need to say, okay, what kind of server big one small one. So that's instance, type we want to know. Is this server going to be in new york? Is it going to be in atlanta, china right so that's region um and other things like that, so this is infrastructure as code. The whole idea is I'm going to go, write some file that basically determines the servers that I want in my environment.

A

So if I want to now have 10 of these servers, I can just run this script 10 times and now, all of a sudden, I don't have to go to the ui to click a bunch of buttons, it's more automated. So that's what infrastructure, as code, ultimately is.

A

So one of the things that's pretty important is that we talk about git ops, a lot. It's really important to understand what this actually is and how to use it. Otherwise we're going to sound we're just not going to sound good in our customer conversations. So let me just talk about how widely used the market term git ops is.

A

If I type in infrastructure as code, there's, 500 million results, if I type in get ops, there's less than one percent of that, so we're talking about literally 5 million down to less than 500 000, so that is less than one tenth of a percent of the search results.

A

um So that being said, what is git ops, git ops is basically an opinionated version of infrastructure of as code. The reason why we market it so much is that, because, if it catches on then this is really good for gitlab. That being said, the vast majority of people don't know what git ops is and a lot of people don't like it. So it's important to really take a step back and understand hey if I'm going in these customer conversations.

A

Let's talk about infrastructure as code. This is something that everyone knows about. Many people are already trying to do this. If I want to take the customer conversation further, because they're really interested in it, let's introduce them as git ops, so they probably don't know what that is. Now we seem like a knowledgeable expert, we're bringing something new to the table, but that being said, the vast majority of people out there in industry right now do not know what git ops is and a lot of people don't even agree with it.

A

So, let's talk about infrastructure as code and what we bring in the table so number one faster deployments. If I want to go spin up like 10 servers, then I can just write. My script run. It 10 times this especially matters at scale, because if, um let's just say that, like I want to go, I have an organization of like 200 different operations, people some of them are going to be new right, they're, not going to know how to go through the ui of aws and figure all this stuff out.

A

That being said, if I had gave them a script, and all I have to do is run this script. I've allowed them to do something really easily that otherwise they'd have to go and figure out.

A

So we're talking about faster deployments, we're talking about lower the lowering the barrier of entry for some of these systems, we're also talking about creating greater security with standardized deployments. So let's talk about why that's the case in a traditional data center?

A

The big problem is: is that if you're a big enterprise company, you have a ton of your own workloads, but you also have maybe 10 20 50 000 servers that came in through all the acquisitions that you had, and the big problem is that, let's just say that, like we have one standard security policy for all of our own servers. Now that we acquired all these new companies, we may not even know if these other companies have security policies.

A

They all have different security policies as well, and so, let's just say that we spent five months really coming up with a great security policy for our linux servers. But this new customer uses only windows servers and we don't have anything over there. So what we can allow people to do with infrastructure as code is that when they define this infrastructure, they can build in their security policy into this, and now tell everyone use this template when you're making a new server because we already hardened it.

A

We know that it's secure so just use this template, and now everything's standardized across your organization.

A

So now, let's talk about some of the benefits that we bring in so one version control for your infrastructure is code and then the ability to perform git ops easily with gitlab ci cd. So let me just show you a little bit about what I mean by this. So this is some infrastructure as code, that's on the gitlab system.

A

Over here I can descend in this is infrastructure as code for defining a windows server with ansible, and if I go into this history section then I can now figure out. Okay, like servers were running great, they were running great, but then they stopped working october 12th.

A

Well now, let's see some, what are the changes that we made in october 12th? Well, the change was this: they added in this thing. So maybe this is where the problem came from right. So the fact that we give history for your infrastructure as code allows you to better diagnose and audit the problems that you have in your organization.

A

It's basically just another way of making sure that everything that you're running is safe. Otherwise, people could just go out and do whatever they want, which is a very dangerous place to be.

B

Is that history only something that gitlab does or do other service providers um do that as well, because that.

A

Seems like a pretty.

B

Unique or I mean it seems like a really valuable thing, not unique.

A

Yeah, so version control is something that's built into git, so any sort of git based system like github and bitbucket they're gonna, have that too.

A

So the value driver that I just mentioned there is something that our competitors have as well, but the whole idea is, you have a lot of automation as opposed to it. Living all over the place could be living on this guy's computer could be living in some cloud server. It could be living on github and, let's just consolidate it into one place. If you consolidate it in the git lab and gitlab is basically the trigger for all of your automation, then now one it's centralized accountability.

A

We know when someone's made a change and two gitlab can streamline the utilization of your automation and provide that overlying layer using gitlab ci cd, where you're making the most out of what you've already written. Now.

A

All right awesome: how often are your customers talking about docker, kubernetes, containers and stuff, like that.

B

um Kubernetes a lot- um and it's mostly like inbound requests um like specific to it like hey. I want to learn more about how you work with kubernetes, yeah and then they'll be like a very specific conversation with the essay and that person um that's yeah, that's pretty much the extent for me. I do know that it's it's definitely something that essays touched on, um because it seems like we have that native integration with kubernetes.

B

I think so and that's something that they they definitely harp on.

A

Yeah, do you know why businesses are moving to kubernetes.

B

um Throughout a guess, maybe it's more scalable or it's more.

A

Efficient yeah.

B

A

Yeah, that's exactly right, um so let me talk a little bit about why that's the case and how we can help. um So, let's just uh talk about containers and microservices, there's a bunch of terms here, um so I'm just gonna talk about what these things actually mean for all intensive purposes. Containers and microservices are the same thing. So whenever you hear a container, you can think microservice. It's basically the same thing, so other things is a container or microservice is like basically like a way of doing things like devops right.

A

But now you need some tools to do. Devops like git lab, so the tools for doing containers is mostly docker and kubernetes. The difference is that if you want one computer running containers, then that's what docker is. If you want 500 machines running containers, then you need some sort of management layer that basically says: okay. Well, this container lives on server one. This container lives on server too so on and so forth, and that management layer is what kubernetes is.

A

So it determines things like scaling and things like making sure that the entire cluster is happy and is up is working as expected.

A

um The other term that I want to talk about is what we call monolith, and so, when you hear the word monolith just think that's the way that all of the old stuff used to be done so um any sort of web application that was written 10 years ago. That's a monolith. Microservices is the new way of doing things and that's when businesses can save a lot of money, so um I'm going to talk a little bit about the difference between models and microservices and why they help businesses save money.

A

So, basically the way to think about it is that for an application, that's written as a monolith, then it basically includes everything all in one for a microservice. You basically split everything out and now let me give you an analogy to sort of explain like basically how this actually works.

A

So, let's just say that you and I needed to print 10 000 pages, because we need to make a bunch of workbooks right. So here's my computer workstation if I told this one printer to 10 to print 10 000 pages. This would take several days. So one thing that you could do is you could get 50 of these workstations.

A

The problem with that is that you don't really need 50 of these workstations. That's 50 keyboard! That's 49! Keyboards that you don't need 49 monitors that you don't need really. What you need is one workstation with 50 printers, which is exactly what we have here.

A

So what we have done with microservices is that we have allowed every single individual chunk of your application to scale individually as opposed to having to scale the entire thing which basically results in redundant like stuff, that's being scaled, you can now scale out your individual component, so let me just give you like an actual technical example.

A

Let's just say that we have some big website and what our data analytics team is doing is that it's running all sorts of different, like searches and stuff on the website to come up with all the data to scrape it off right.

A

So what I want to scale is everything that's related to the parts that it's scraping off, but I don't really care about certain other parts that aren't being utilized right, so the database is probably heavily being used right now, um things that are endpoints that it's scraping off are heavily being utilized right now, but all the regular stuff, like the welcome screen, the um you know stuff that they're not scraping off, isn't being utilized at all.

A

So why don't we just scale out the stuff that they're actually doing and um that and are interacting with so at a high level once again monolith? If you need to replicate it, you have to replicate the entire thing with a microservice.

A

You can now replicate your individual piece or business function and it's the same thing as us. Trying to replicate this workstation 50 times. That's 49 printers. We don't need 49 mouse. We don't need to now just having one workstation with 50 printers, which is ultimately way more efficient. So that's the reason why businesses are moving to microservices.

A

Is that that's the technology that allows you to scale your individual component that is actually in demand.

A

So that's one piece of the tape of uh the puzzle, which is cost savings, we're talking about very significant cost savings. If you think about something like netflix or something like youtube, then a huge chunk of your cost is all the servers that you're running. If you can make that 20 30 percent more efficient, then you have a huge advantage over your competitors over a three to five year time horizon, and so that's when they're one of the reasons why people are going to containers.

A

The other reason why people are going to containers is the fact that they scale way faster than traditional architecture, and so, let's just say that this is a scaling virtual machine. So right now um it starts out. We have three vms and this is an auto scaling application.

A

More people are hitting our website around 10 a.m, so we're scaling up and then people are getting off of it until 1am 1pm right. So it's scaling back down. So if you have really really jagged lines like this, then that basically means that, because it takes so long to scale I'll, just give you an example.

A

It takes about three to five minutes for a traditional application to scale. So if a lot of people are hitting your website all at once, like you have a nike flash sale, then that's going to be a really poor user experience. It's going to be really slow and people are going to lose interest right.

A

um So contrast that, with a container, if you had a container, then you could scale like this, where it's way way way more granular. If more businesses people are coming into our, if more people are visiting our website, then it can scale extremely quickly all that matters for a customer, because that's going to allow that website to be more robust and be more fast, especially for a dynamic, like utilization rate, can I help clarify anything with this. I know that this is pretty.

B

Complicated, no, it makes sense. Okay, great! Thank you, yeah. I think the analogy really helped um like the printer analogy yeah, because it gave me like a that, gave me a really good, like baseline understanding of like okay. This actually like this is what it is from like 50 000 foot level, and then I felt like it really helped them to dig further deep, so yeah um yeah.

A

B

A

Cool awesome, so let's talk about some of the benefits of containers and some of the challenges, one. You save a ton of money in terms of the servers that you have so, let's just say that it costs 10 billion dollars to run all of your applications. If they're in the traditional way. If we moved everything containers, maybe it would cost us five million dollars we have now.

A

Maybe fifty percent cost savings, I'm kind of making this number up, but it is significant, and now I can have a lot of money that I can play around with and do something else. That's going to drive value for our business two.

A

If you're using containers, then you have more reliable applications because of the fact that they scale better, and so what we're talking about is netflix guarantee you, a hundred percent that netflix uses containers google uses containers all of the best applications today they use containers, especially the ones that are massive for huge enterprises, especially in the tech space.

A

So some of the challenges with adopting containers is that it's a really large technical challenge. You have to basically break down your applications, rewrite a lot of logic. You have to hire people that understand how to do this, that aren't going to screw it up. There's a huge skill, talent, job gap for hiring these engineers, and you need tools right. So it's basically a brave new world people are getting started in this way of doing things right now. There are some people that have been extraordinarily successful at it.

A

70 percent of the market still trying to figure it out, and some of them are really getting stuck because it's hard to do this, and so it's important to understand that right now, container adoption is minimal, but this is going to become more and more popular. Every single business in the tech industry right now wants containers probably has some project adopting containers but 80 to 90 percent of their workloads aren't written for containers, yet simply because they don't have the time to update their systems, but it's something that they want to do.

A

This is actually really good for gitlab, because gitlab was written for containers as more businesses start using containers. We're going to be able to drive more value for these people. What is gitlab bringing the table one? We make it easier for companies to get into microservices because we offer so many of the tools that they need to do this. So we include container storage. So that's what our docker registry that basically is like a storage facility for containers and container save files.

A

Other things that we do is we'll monitor your kubernetes applications. So if you have some sort of application, that's running in kubernetes, then we'll give you that real-time performance log of how much what percent of capacity are you at? Are you at 20 capacity, 80 capacity, 50 percent capacity? We do all of that stuff for you.

A

So the whole value add is that git lab is built for containers. Get lab. Sas literally runs on kubernetes, and so this is something that we know really well around. 20 to 30 percent of all of our product. Functionality is only works for containers right now, so other things is that some of our deployment methodologies so like rolling deployments stuff like that, that is best for kubernetes. We are really really great. If you are thinking about investing in kubernetes and containers,.

A

All right can I help clarify anything about containers before we wrap everything.

B

Up you know if we have a place in salesforce that tracks um who's leveraging the lab and association with kubernetes so like. If I was a sal, I could go and find like a specific customer um who is actually using us for that reason or migrated us to us. For that reason- and maybe this is just like- I could go- pull a case study and find that out. I'm sure I could I was just curious if there's like a box for that, I doubt.

A

It, I really highly doubt it.

B

Well, it would.

A

B

Interesting to track over time, how that sort of caught on.

A

Yeah, I will say that in the last three years I used to when I was selling three years ago, like kubernetes, is something that half of people had heard about now in every single customer call that I've been on, like basically kubernetes, everyone knows where kubernetes is, and now people are trying it and well. Some of them are successful with it. Some of them aren't, but that's only going to increase in time.

B

Yeah I went to cubecon like what was it three years ago. um It was huge, so I'm sure, like I mean.

A

I can't imagine.

B

How much it's growing since then yeah so yeah is there a um because kubernetes is owned by google right, yeah or developed by them? Is it.

A

It was something.

B

A

By gitlab by google, and then google decided to make it open source.

B

Okay, so that's good to know actually.

A

That they did, that like they could have made a lot of money off of kubernetes, but they decided to open source. It.

B

Yeah, I wonder why, like what was the thought process behind that because it seems like it would have been something really unique to add to like gcp yeah, one of their like huge things. I could see a lot of customers coming their way because of that.

A

So just some questions to ask once again: these are really great universal questions that we could ask any customer and the reason why is because basically, every single business, probably 95 percent of businesses today they are migrating. The cloud 95 percent of businesses are leveraging automation, every single person that I've ever spoken to. They want to leverage automation more and then so. When we can talk about hey, we can maximize the automation that you already have and let you get more out of it.

A

This is something that basically, everyone wants right and other things like microservices, it's another huge driver and the whole idea over here is these are things that businesses are already doing. These are really complicated things that take around three to five years to do, but businesses want to do them quickly and gitlab can help.

A

So some of the questions that we can ask is: what are you currently doing for cloud? If it's uh adopt, if they're currently adopting it, then you could say: do you? Would you like to learn about how you can maximize your cloud investment? If they already have a mature cloud implementation? They can talk about. Would you like to discuss how to adopt vendor agnostic cloud practices and things like that?

A

But the whole idea is asking these questions asking about their initiatives and talking about how gitlab can become a strategic driver so that we can help them to solve some of these long-term problems that they have.

A

So, let's just wrap everything up. Solution selling is superior for complicated customer scenarios. This is replicated by many many many studies, and the thing is that in the technological space then solution selling is in general, the best way to go simply because these are really complicated initiatives.

A

The four initiatives that our customers are currently facing, that we have a plan are cloud migrations, automation, infrastructure as a code and adopting microservices.

A

We can help these customers solve their problems with each of these by telling about some of the capabilities that we have surrounding all of these things, and so, when we combine a solution, selling approach to some of these common customer problems, we can drive of engagement and have better sales results. So that's the presentation today thank.

A