Discussion with GitLab: DevOps tools vs DevOps platform

Adrian (00:06):

In this sort of harmonized world where we're encouraging a reduction in the tool set, I think there has to be journey for that. And that really means that platforms have to provide integration with other tooling. And that could be for a transitional period, but it could be that an organization has a particular tool that for whatever reasons they want to stick with, they want to stick with permanently, or at least that's their view at the moment. So being able to support those integrations is important.

Lauri (00:38):

Hello, and welcome to DevOps Sauna Podcast. The DEVOPS Conference is happening again on March 8th and 9th, and you are invited to join our event. And if you listened to this episode after the event, don't worry about missing the opportunity. You can watch and listen to all speeches online. While DevOps is indisputably about culture and processes, we cannot disregard the role of tools. Where both terms DevOps toolchain and DevOps platform emerged at around 2010. The term DevOps platform is now about 10 times as popular. What does it mean? And what's the difference between DevOps toolchain and DevOps platform? We invited Adrian Waters, Solutions Architect from GitLab and Kalle Sirkesalo, a CTO of Managed Services at Eficode to discuss the topic. Let's dive in.

Lauri (1:35):

Welcome to the DevOps Sauna Podcast, Adrian and Kalle. 

Adrian (1:38):

Good morning! And thank you very much for inviting me along today. 

Kalle (1:42):

Thank you for also inviting me. 

Lauri (1:45):

Thanks for joining. I have been now talking to quite a few people about topics that we're going to cover in The DEVOPS Conference, and many of them revolve around DevOps surprisingly, and there was a very good definition, I think it was in Nicole Forsgren's synopsis. I'm maybe paraphrasing it, but the synopsis said that DevOps was originally about taking care of people while they create great software. And in this respect, you could say that people is the most important factor in DevOps, and then comes processes and then comes tools. But without the right kind of tools or with the tools itself, it would still be an incomplete picture. And today, we are talking about tools. I believe you agree with me that when the tools part is done right, then we can focus more on people and processes because in a way we have gotten the tools questions out of the way. 

Lauri (2:45):

We see that there is a movement going on in this tooling space. And I have seen that movement before in different industries where you start from a situation where you get the best tool for each purpose, and then you basically integrate them together. And then in the course of time, these individual small tools that does one thing well, or that do one thing well, then they congregate into bigger entities. And then eventually, we start to talk about single tool for the whole business process or majority of that business process is going to be catered by one tool. So let's start with the open question. Where is this tools space going and what are the trends there, Adrian? 

Adrian (3:32):

Yeah, I would agree, absolutely with that. I think we see within our customer base the sort of desire to move to a more consolidated approach versus sort of distinct tools. And I think that's also been seen in the industry as well. I mean, Gartner have published their value stream development platform guide, which the update last year was saying that by 2024 and 60% of organizations will move to a platform approach rather than individual tools, which given that's only two years away, that's up from 20% now, that's a really large increase and it does reflect what we see, I think.

Adrian (4:13):

Looking back over the history of DevOps, you know, from initial team-based approaches, every team choosing their own tooling and then sort of attempts across the organizations to standardize on particular tools, particular aspects of the life cycle, but each department still managing themselves through to then attempts to sort of provide a more sort of integrated approach to those tools. Those all, that direction has all had benefits, but it still has left organizations feeling that they really haven't yet got the true benefits from DevOps that the investments that they've put into it, you know, should have resulted in. So they haven't achieved the agility or the speed, or the quality of delivery that they were really aiming for.

Adrian (5:00):

I think there are various reasons for that and one is where you have a sort of a multi-tool approach, you're often still having a sort of a siloed approach in many ways, because you've got different users across the DevOps life cycle, utilizing different tools. So that then feeds into the people in the process side of things. And that's one of the areas that by adopting a more platform-based approach, you can try to remove those silos from a technical perspective, but more importantly than the knock-on effect in terms of people in process. 

Kalle (5:38):

Yeah, I think this is mostly about… tools don’t really matter if you're a top expert, if you know how to do DevOps and you're like already doing DevOps properly. You can do it with par script. You can write a par pssscript and put it in a current job and have it running and figure out what you're doing. You really solve the way to go fast. You will solve the way to use it often and continuously, but the support large scale for a while, like if we're talking about over 8,000 developers at one time, you can't do that in a postscript. Nobody's able to help someone with their par script if they have that running. It's the same thing when you have, like, when you start adding tools, you add complexity easily. If you have very well-defined documentation and ways of working, it's very easy to get in on those multitude of tools. And you're focusing on people at that point. But if we look at big corporations or big movement, and even small movement, you don't usually have time to write. This is how we DevOps software, this is where how we are going to do it. It makes work more sense that you come in and you see, oh, this is how everybody's doing it. I can do it exactly the same way because you have those in their sourcing and comparable solutions available. You're seeing what doctors are working by just entering into the tool and having the same tool everywhere means that it is a lot easier to get those DesignOps, SecOps, whatever Ops you want in there because you can share those examples. You're not limited by, oh, but you don't have access to this tool because everybody is in the same tool already.

Kalle (7:12):

Yes, some features might not be in your USP because you are not able to use them, but at least you can share information, and if and if you are like, yeah, but you can't access it from this network, you need doctor tool for that. That gets removed If everybody's got trying to work on the same tool because you're like constantly thinking, how do we make this storing space so that anything that someone does works the same way for the others, which means that then it becomes more of the communication together. I think at least that way. 

Adrian (7:40):

Yeah, I think  there, you said sharing of information you know, I think where you've got separate tools that becomes more difficult. Yes, I mean, often, you know, you'll see organizations that have built their own sort of platform around the tooling, or they've attempted to, but that's not straightforward. And you know, if you're extracting data from one tool to map the data in another tool, that is not always simple. You know, entities might have sort of slightly different meanings, so that becomes a sort of a bottleneck and it decreases collaboration, you know, and obviously we know that collaboration is absolutely key to this sort of life cycle.

Kalle (8:22):

Yeah, it makes everything like if you think about managing from top-level or managing from any level, it becomes impossible when you try and discuss with the customers like… or like your employees: hey, this is how we do it. But if you have 20 Yankees that work differently, you have 20 different things that you have to communicate to those teams. So you're not communicating. Hey, you can just deploy this Docker image for example, here, and it will start working. No, you have to do all of the other steps. Like if you are in this tool, you have to go here. And as we know, the more ifs you have in a sentence, if you work at SonarQube, for example, or any code… static code analysis, you see the complexity going up when you go deeper. And in big corporations where you have many tools, you have to depth going in, like somewhere like 50, you have 50 different tools at the end, you have a different kind of like subsets of what are you using. And I see as a trend, we want to simplify things because we are talking about the programmer, like shortage, which I don't agree completely. I agree with half of that, but I also have created, we have a junior problem, but anyway, that's a downtrend that we have, which affects this. So we need to improve the capability of our experts. 

Adrian (9:35):

Yeah, and consistency is key because you know, the way the industry has gone in terms of cloud native and microservices, there's more and more things to manage and to collaborate on. And so having that consistency, you know, it means it's easier to bring people on, you know, to say this there's a shortage of staff, there’s no question about that, I think, but if you can bring somebody on and get them up to speed quicker, you know, quickly, then you know that's a real advantage. And I think this sort of harmonized approach aids that.

Kalle (10:10):

Yeah, I think consistency is very good. Like if we look at, for example, restaurant world, if you have seen My Million Pound Menu in Netflix, it's about investors trying to invest in U.K. restaurants, which Adrian probably has eaten. They always talk about that it is important to be consistent in your food. And it's the same thing in anything. Like if you're not consistent, how can we know what do you get out in the next week. You need to consistently bring out the same thing. 

Lauri (10:39):

And I think that's an essential part of basically continuous improvement is you first address variability and only after you address variability and you have some sort of predictable quality or predictable value, then you can start improving that based on the predictability. 

Kalle (10:56):

Yeah, and I think that is what brings you to the organization; challenges and problems that they have in the transition. 

Adrian (11:01)

I was going to say that point is really, really valid. And if you look at all the different point tools that people will have used in the past in all of the different areas of the life cycle, you know, there's some great tools out there and they do a fantastic job in their area. But because of the challenges that we just talked about, consistency and silo, and so on. That doesn't mean to say that overall the enterprise gets the best out of those individual tools. And, you know, I think what we've seen is, you know, from a platform approach, the functionality in a specific area may not match exactly the functionality of a third-party tool, but the improvements to the overall operation and effectiveness because of the seamless integration outweighs that it doesn't have feature XYZ. And that can sometimes be a challenge for organizations when they sort of are looking to move, or consider moving to this different way of working is you can get hung up on, has it got featured X? Has it got feature Y? But if you look at the bigger picture, the benefits that you'll get from an overall workflow, effectiveness, being able to shift left collaboration, things like governance in ordered ability, those outweigh those specific items, functionality, or at least they are something that should be explored.

Kalle (12:27):

Yeah, and [unclear 12:29] showing that usually comes with this is in heavy compliance industry where people are constantly like, but we need to do it this way. And you're trying to ask, what are we actually trying to get out of here? Like, what is the actual, like clients' requirements that we need to feel. So if it's separation of duties, why do we have to do it this way? Can't we like actually think about what do we mean by separation of duties? Not try to make data work like Yankees, for example. We are trying to make it work like it's supposed to while supporting a separation of duties, we are not supposed to start inventing that heavy. Now have two Yankees. The idea is not to have two Gitlabs, the idea is to have one Gitlab where we define permissions so that you have the separation of duties ongoing, instead of like trying to… and that’s a big organizational problem that organizations think that they can do the same thing everywhere, which is not what they should be thinking. They should be thinking, what are the actual challenges they're trying to solve? 

Lauri (13:27):

Yeah, I remember from procure-to-pay business process, there was a time about 15-20 years ago when a lot of organizations went from paper-based ordering and paper-based payments to digital ordering and digital payments. And in the beginning of 2000s or so, they did have a major body of work to think through how should digital ordering and procurement and digital payment and accounts payable, how should it look like? And maybe in the course of 5-years, within 2005, 2010, they got it right. So they had a process that fit them and then come 2016-2017 when there was this SaaS thing suddenly up and all of the services were going to SaaS and companies had to replace their procure-to-pay on-premise software with theSaaS software. There was invariably this question that it doesn't do this A, it doesn't do this B, it doesn't do this C. So we need a feature parody. And that seemed to be a massive issue in terms of SaaS adoption until it sorts of clicked both on the vendor side and the customer side that it's pointless trying to bring over a 10-year-old business process to a new platform. 

Lauri (14:44):

What do you have to do is go back and ask yourself, is this business process now modern enough? 10 years have elapsed, has something happened in this business process front that we could actually rethink these process part as we are transitioning to a different tool. And that was one of the challenges that organizations were facing during those transitions. Does that ring a bell in your case? And what kind of challenges would you say that organizations have transitioning from my old world to the new world? 

Adrian (15:18):

A key challenge is to avoid the disruption that would be caused by a big bang approach. If an organization is using several different tools today and they want to move to a platform approach, you know, both from a technical but also people in a process perspective saying like throw all your existing tools on day one and move to the platform. That's probably not going to be the best solution. So although in this sort of harmonized world. where we're encouraging a reduction in the toolset, I think there has to be a journey for that. And that really means that platforms have to provide integration with other tooling. And that could be for a transitional period, but it could be that, you know, an organization has a particular tool that for whatever reasons they want to stick with and they want to stick with permanently, or at least that's their view at the moment. So being able to support those integration is important, but as a slight difference or a fundamental difference really to that versus the historic approach, gluing together many different tools across the DevOps tool chain or life cycle, in the platform approach, you're integrating each tool into the platform.

Adrian (16:26):

And so that helps to extend the platform whilst retaining, you know, many of the benefits that the platform provides. The things that we've talked about, collaboration, common data stores, and so on. So I think working out for each organization, what is the best approach for them in that transition is really key. One of the things that we've seen within our customers is that yes, day one, their vision or their view is that they will adopt. You know, Gitlab as a platform, but they have a specific tool that they want to maintain because of the way it's used within the organization. But from experience, what we find is that over time, they recognize the benefits such as we talked about before that rather than comparing specific functionality within tools, look at the overall benefits, the overall value that it delivers, and the improvements to the workflow it delivers.

Adrian (17:25):

And so, we find that, although customers set out with the view that, yeah, we're going to stick with this other tool indefinitely. They sometimes will realize the benefits and you know, change their mind over time. And so gradually we find customers adopting more and more to the capabilities instead of maintaining separate tools going forward. And I think that just reinforces the benefits of this overall approach to the life cycle. 

Kalle (17:52):

I think that's.... Talents is usually trying to explain to top managers, even told this tool does everything that the other tools do. You're not supposed to replace everything at one go, you're supposed to do it like in batches. You're supposed to think about like, how can we enable the teams effectively? So we don't go and disturb their work. We are going there and we are going with KPIs or something. We discuss with them and create key KPIs, what are we migrating and what can we migrate? And what do they migrate when they have time and what would that be to enable capabilities, and a multi-cloud feature, for example, like, do we have every cloud support on day one? Probably not. Let's start from having one cloud supported, and then add the others when they get people onboarded. Because having, for example, EKS cluster, AKS cluster, and TKA cluster running on day one is a cost overhead versus when you don't have people running there yet. You want the EKS cluster, for example, if you're running an AWS because you will have AWS customers already coming in most likely. And then you add AKS cluster, or the TKA cluster, when you get those customers running in and they are doing the appointments, you don't want to go from, hey, we purchased this develop ultimate license, for example. Let's get everything up and running on GitLab.

Kalle (19:13):

You want it to go more like, hey, now we have a capability of doing this, let's inform teams that they can, and let's tell them that we will enable any features they need, but let's not do it all at once. But rather like according to what is needed. And then we start looking at the map and seeing where is the holes and allowing those. In my opinion, that's a big challenge for organizations, to not see that you can do, especially with GitLab, for example. It's very hard for the customers to see that oftentimes you don't have to take everything into use, even if it does everything, you can take it in parts because it is built so that you can… you don't have to do everything at once as you can do it like:okay, now I have STM in use, and now I have added CI/CD, now I have secret management, now I have added dust Kubernetes cluster deployment. That's it. So you don't have to do everything. 

Adrian (20:05):

Yeah, no, absolutely. And you know, that is the experience within our customer base is that they will focus on the key areas that will give them, you know, the quickest routes to achieve in value. But then typically then over time, they will extend the breadth of the capabilities that they're using and also the depth of the capabilities. But the multi-cloud is really important, you know, even if customers have got their favorite cloud provider today, they're typically still looking at having the capabilities to either supplement that and have a true multi-cloud or really to be aware of, you know, well, what would be involved if we did want to change our cloud provider? And I think given the comfort that that can be accommodated without too much pain is important. And again, that platform approach sort of helps with that. 

Kalle (21:03):

But in my opinion like, it's stupid to design every system to be multi-cloud immediately, but it is also for an enablement platform, like DevOps platforms are, DevOps tools are. It is also not good if you don't learn it so that you can support multitude of clouds, for example. You have to be able to switch the DevOps tooling to support whatever you will be doing. And that has to be… that is the integration part. That is the working part, like it’s the cloud support part, because you have to be able to support the teams in many different approaches. And that's why it's important that the platform can be integrated to new tools also, because that means that the new tools can be taken into use are destined. If for some reason, something isn’t available in the tool itself, because innovation is a big thing and innovation is something you need to do. 

Lauri (21:53):

Would you be foreseeing one team adopting it fully and then go into the adjacent teams or would you see all teams adopting one functionality fully and then go to the next functionality? 

Adrian (22:05):

I think we see both scenarios. I think there's great benefits in testing out and proving out that adopting a certain parts of the tool is going to really give benefit. And, you know, as an organization, you will then learn from that and be able to then apply that as you extend it out across the organization. And you know, that sort of approach, sort of iterative approach is core to how GitLab operates. You know, it's one of our values iteration is that - do something to improve, test it, measure it, and prove it, gather feedback. So, I think that is an approach that really convert well across our customer base. But we do see both. And I think one area, you know, that's where that fits in is things like security and application security. It's quite a different way of working than maybe organizations have in the past, how they've managed their security side of things. Again, the big bang approach of rolling that out right across the organization is probably quite a scary thought. So, been able to test that out within particular areas, particular teams; it definitely gives advantages. 

Kalle (23:17):

I would say that like, the question is kind of malformed, because you expect you're doing just one of those, but you're always doing both of them. So even if you would decide to go wide, some teams will want to go deep. So, we need to be able to have the support functionality that can go deep with those teams that you are training who want to go deep. Some people are really like lovers of the platform, whatever you choose. They like to do like it. And they like the concept and they are like following the trains. And those guys want to go immediately deep and you need to be there and ready to help them. But I think it's more about the strategic view. So if we look at, for example, a pricing model, if you haven't yet decided that you are going all-in on one platform, then, of course, you want to go deep. But if you have decided that this is where we are going, and this is what we are going to go and do, makes more sense to get everybody into, for example, GitLab environment, have them migrate there in an STM function, have to keep function there and allow them to start working with the Git. That enables and has the features available, like safe runners, for example, enabled. So they can start deploying CI/CD because then they are already users to platform and they are like, oh, there's actually a button here. And I get out of DevOps to create me a CR pipeline. So let's see what happens. And then they got to start testing that themselves, you don't have to be there the whole way because you want those teams that are interested to be able to already start testing out and doing things that they can. Once again, innovation. You want to enable the innovation of the users and also remove that load from you of moving the users to your platform because they are already moving there by kind of like, oh, it's actually, I can do this and that here, that I couldn’t do here, or it's very easy to get these things running here. Like for example, secret detection, dus-dus, separated features that we were talking about. 

Adrian (25:11):

Yea, and I think having those teams that do want to go deep early is valuable because they can then surface their sort of thoughts on best practice for adoption across their organization to drive that. 

Kalle (25:24):

I have one thing that is quite very weird, which is that the highly adopted DevOps teams that are highly like capable are actually diverse teams trying to get to Gitlab because they have to most things to migrate to GitLab, for example, because they have already taken in 20 tools, spread the tools, for example, to make their pipeline as good as possible. And it's a complex pipeline, most likely because they have all the things done so that they can deploy fast and automatically, but neither out of controls. So those teams are actually the most advanced teams, are usually the diverse teams to start the testing because they are not the ones that you targeting when you're doing it, you're targeting the mass. You're trying to get everybody into DevOps. You're not trying to get the best of the best to be the best, you're trying to get everybody on a decent level, at least. 

Adrian (26:13):

Sorry, I was going to say that that's a really good point and larger organizations will have… got some decent maturity in their DevOps processes. However, they've gone about it. If you look at some smaller organizations, they may not have that maturity. They will in certain parts, but you know, maybe they've not really looked at application security in detailed as yet. Whereas larger organizations will. I think where you've got that expertise and that deep expertise, and they've developed their own ways of doing things. It then, you know, can become a… well, let look at what it costs to maintain that, you know, in terms of efforts and third-party licenses and so on. And those are then considerations that maybe not day one, but maybe in six months a year, or whatever, you then can look to see, okay, well, the platform will do it this way. This is, you know, within the license that we're already paying, this is what it's costing us to do it this way. What are the benefits? Could we get more benefits out of switching approach? And you know, one of the key areas where we see that is around security. So, you know, security is becoming ever and ever more important. And things like… the recent vulnerabilities that are being found, you know, that brings it back to the fore, but the benefits of baking the security, you know, right into the day-to-day workflow of the developer is much easier to achieve if you've got a sort of platform-based approach, rather than if you're using a set of, you know, different tools. There are very good security tools out there. They tend to focus on one or two areas, whether it's static analysis or a dependency management, or container scanning. Whereas with a platform, you can get all of those different types of scanning and vulnerability detection, and then be able to report it in a consistent way. And in terms of detection and remediation and that then reduces a lot of the complexity and effort that maybe those teams before I've been trying to build themselves and have them to maintain themselves. So that's one area where we see that example is that, yes, there's something very matured in place, but does it provide the work flow benefits that you really want to try and achieve? You know, there's shift left paradigm, bringing security very much into that and into the realm of the developers rather than leaving it in the realm of the security team. 

Kalle (28:47):

I've seen the security shift bit by bit that everybody's talking about security, but it's like what big data was, everybody was talking about big data. But very rarely did you face teams that were actually doing like these proper terms. So it became like for me, I see security being there and being talked about and everybody wasting SAS, Dus, etc. And then I go there and I see that there is no process, no tooling, no nothing there, because nobody wants to invest any money on it. They just want to talk about how they need to do it. But they want to do it [unclear 29:20], for example, then you have bunch of open source tools and you're trying the parts to get out of the matrix. So I guess, you Adrian have seen people doing more like common metrics and using tools to get there. Is that. Has that been like a bigger trend ongoing in your views or has it been more of the spotted-friendly thing?

Adrian (29:40):

I think there's been a real shift in the last 12-18 months in terms of the adoption within our customer base of our security capabilities. The developers aren't all security experts. And so, you can't expect the development teams to have the expertise of the security teams, but if you can create a work flow that highlights back to the developer, you know, you've just made a change. Oh, look, you've now got these vulnerabilities. There's either a chance that the developer will be able to look at, okay, I made this change., this is the impact. I'll resolve it, I will sort it myself, but if not being able to, you know, easily and effectively raise up to the awareness of the security professionals and to have controls in place to make sure that that vulnerability doesn't go anywhere until it's had eyes on by the security specialists. And they've sort of said, yes, this is, you know, we need to sort this or no, it's okay as it is. And that sort of shift to make developers more responsible for security and the changes that they're making benefits them because ultimately they will be able to resolve their own issues, you know, the majority of them, but it also reduces the workload on the security team and allows them to focus on the real problems that does need their expertise. And being able to report all that in a consistent fashion and re-mediate in a consistent fashion is pretty compelling. And I think that's driven a lot of interest in the security side of things, you know, it's making life easier. It's improving the workflow. And you know, that's a pretty compelling message. 

Kalle (31:29):

Yeah, and I think like big thing is that if you can’t remove all of that messy detectable and overstocked programs out of this application, 80% of the companies in the world are secure with that because most companies are not being attacked by like a targeted attack. They are being attacked by bots and so on. 

Adrian (31:50):

Yeah, and the other key area is open source. You know, the developers are using more and more open source and we've seen recently, you've had a solution in there. You've got software running. You're quite happy, you know, you think it's free of vulnerabilities and then, you know, suddenly something out there happens and you find, oh no, okay, we've got a problem here and having the tooling to help you identify where does that exist? You know, what's the impact to us? Even something as simple as a pile of materials to be able to identify, you know, where you might be exposed to one of these new vulnerabilities that have been identified as really, really important. 

Kalle (32:30):

It saves a lot of time on that case. Like, yeah… 

Lauri (32:35):

I am out of time people. 

Adrian (32:37):

It saves time. It de-risks, it gives confidence in what you've got and you know, that’s a key part in security.

Lauri (32:47):

It’s Lauri again. There are countless details to think through when trying to make the right decision about the toolchains and platform, how to host the solution, which technologies to select, and how centralized or flexible you want it to be? We have written a guide regarding your approach to toolchains in your organization. True. There is not one solution that fits everyone, but our advice will help you find the right direction for your organization. You can find the link to the guide in the show notes. Now let's get back to our show.

Kalle (33:21):

It was funny reading both today, when we are recording, this has been Work Force J, of course, or Work Force Sale as people have been saying. It was funny reading the response from Work Force J where they were saying that like, yeah, we have zero errors that we have gotten from this whole code that we have been up-keeping, but all the corporations have been putting us responsibility of keeping backwards compatibility, and now that the backwards compatibility is hitting them, they're complaining that we are in fold for doing open source. So it's kind of like keeping your safe by doing these things properly. So how did the built materials allow you to recognize this and not play the open-source developer who is just doing it on his free time most likely? Because that's not where to blame is, that person is most likely just developing it when he has time. But if you have to like knowing when to fix things. 

Adrian (34:10):

Yeah, absolutely. 

Lauri (34:12):

You made a point there before that it's probably not the most beneficial thing to start from the most mature teams. And that makes complete sense, that argument makes complete sense when you think of metrics and think of metrics as an average metrics, and that you could say that there are teams that just haven't gotten to this basic level. Let's say identification of who made the change or commit signing or things like that. Then I could imagine that when you adopt a platform approach, it's easier to focus on those very basic things to get everybody on the 80% level. So I just wanted to bring that up in the security context that, yes, there's a lot of stuff that you can do on the advanced course in security, but when you take the basics out of the picture, then that's very helpful. 

Adrian (35:05):

Yeah, I agree. I think that it goes broader than just the security side. You know, there's a lot of focus these days on value streams. And I mean, all teams utilizing a platform, albeit that different teams may be doing it to different levels of maturity. It gives you a common basis on which you're sort of, you know, value streams can be measured in the analytic. So you can start doing things like comparison between teams. You know, which teams are proven to be more effective than others. If we make changes to, you know, maybe where a particular team is working, how does that reflect in their performance from an analytic perspective? So having that sort of common base, it gives you all sorts of opportunities to measure and then improves the performance of teams to try and bring them all up to the best in breed. 

Kalle (36:00):

The very first thing you want is to get everybody in the same authentication even. When you have 20 different tools and you have 20 different permission models that you are managing, which means that you have 20 different things that people need to remember when they are boarding in, or if you have managed to actually do that proper IEM project, you have everything coming from one source. I have not seen that happening in any enterprise I've worked with so far, that they would have one place where you're quick and you get the permission where you need it. But rather you are quick, you get the first approval. You forgot to apply for that adapt purpose. So that you're like, okay, yep, I applied. It goes to your manager and if they need to approve once again, and it just keeps going. I've seen a lot of, almost good ones, but like with GitLab, for example, you can, or any other like platform solution, you can so it so that you have on a single sign-on once and the permission model stays the same on the whole platform that you're inside of. So you don't at least have to think about all of these things multitude of times a day. 

Adrian (37:00):

And the other area is also traceability. You have sort of complete traceability from, you know, initial thoughts, requirements through to your application running in production. And so, if you identify problems in production, having that, clear traceability back really aids that root-cause analysis, improve in times to fix more quickly. 

Kalle (37:30):

Especially when you have like a… yeah, go ahead.

Adrian (37:33):

I was going to say as a bit of an extension to what we were saying a few minutes ago about analytics, you know, the DORA 4 metrics are well-known within the industry, but for companies to measure those themselves would be a real challenge where they've got data in different silos from different tools, and they also then have to start making assumptions, across those different tools and the different data-sets. So again, sort of unifying that data within a platform makes it much more possible to look at that sort of aspect. And that allows you not only to from analytics compare internally within your competitors within your own team, but also look to see, well, okay, how are we fairing in compared to these industry metrics? How are we doing versus our competitors? 

Kalle (38:25):

And it's also like the whole thing of having that like continuous deployment, which most companies are not at but where everybody's trying to get to. So if you're constantly deploying and seeing what is being deployed, you get the audit work of - did everything work as expected? Because you're collecting the metrics hopefully, directing to app, and you're seeing the release as you're seeing everything there at one place, and you're seeing like, oh, we release this, at that time and that lead to this performance degrade. And you don't have to build all of that yourself. It's already built into the system if you're using the whole platform so to say. So there is lots of possible benefits that you can get from having everything in one place. 

Kalle (39:08):

Of course, you can built this yourself also, but then you're building it yourself. 

Lauri (39:12):

And maintaining it yourself. I think often building things, yeah, you can do it. It will take whatever amount of time it takes. The real cost often then comes into maintaining it.

Kalle (39:28):

What was it? 80% of software costs come from maintenance and upkeep. That was at some point the number. Like 20% is the cost of development, 80% is the cost of upkeeping and maintenance. 

Lauri (39:42)

I think somebody had a wonderful expression, which was “Free as a Puppy”. As in, if somebody offers you a puppy, the puppy is free, but it takes a toll to upkeep that puppy. And I imagine that it goes with many other technologies as well. We could not talk about GitLab without talking about working remote. And we had somebody from GitLab joining about a year ago, who was your Head of Remote but let's talk a little bit about the benefits that companies are seeing, like GitLab as a company, but also like what's the connection between the platform approach and remoting now that we all have had to do that for a long time.

Adrian (40:28):

Yeah, that's a great area to talk about. Maybe just for listeners who aren’t aware, GitLab is now a remote company. So, we don’t have an office anywhere in the world. Everybody is home-based. Some may choose to work in co-working spaces, but do not have an office. And you know, there are different ways of doing remote and I've seen both of those during the pandemic. GitLab was in a pretty fortunate place at the start of the pandemic, because we're already used to working remotely. So it was pretty much, you know, business as usual for GitLab. Whereas I experienced others who were office-based, who suddenly were working from home, and what their organizations tried to do was just say, okay, you're rather than working 9 to 5 in the office, you're now working 9 to 5 at home, and they more or less tried to keep, you know, the same processes that they would normally use and it just didn't work. So I think one of the things that GitLab has developed over its life is a very effective way of working remote in the way that we handle meetings, we go to great lengths to avoid isolation, you know, people working in isolation, and some of the tooling and the ways that we work reflect that and actually using GitLab itself as a product is a big part of that because it supports collaboration. So, you know, we've been talking today about Gitlab as a platform for software development. Internally, within GitLab, we use it for that, obviously for the development to GitLab itself, but we always run it… also use it as a core part of running the business. And so non-technical users, our marketing folks, our sales folk, and so on. We'll all be using GitLab and we'll be using capabilities to ensure that collaboration, and I've worked in full-time in offices in the past, I've worked from home where companies have had an office. And that's a very, very different experience because, in all sorts of scenarios, things still happen in the office.

Adrian (42:42):

And when they happen in the office, they forget about the people who aren't in the office that day or that week. And I think that is a challenge for, you know, going forward, more and more companies will support remote working, but in a hybrid, many in a hybrid approach, they will, you know, expect employees to come into the office for two days a week or whatever it may be. And I think they will need to adjust and look at to make sure that it's effective, you know, whether somebody is in the office or whether somebody is remote. You mentioned we've got a Head of Remote, which is probably not too common a job title, but his focus is on that remote work. And he has published a lot of information. There's a lot of information on our website. We shared again during the pandemic how we do it to try and help other organizations who were forced into this way of working, you know, very quickly. So if it's a topic that you're interested in, I would suggest to go into that, but I think the key thing I would say… You know, there will be a drive from individuals to be able to work from home, at least some of the time now. I think the pandemic has changed that, but I think companies do need to think about how they do that, how they support those users whilst still maintaining the more typical sort of office. It's not the same. Just saying, okay, you're not sitting at the desk in the office, you're sitting at home, you have to think of it more about it. And I think there's a lot to be learned from how GitLab have handled that over many years. and for us, it's worked from, you know, when the company first came into being like 10 years ago. As we grown to the size and scale we are now, you know, spread across, I don't know how many countries, nice 65-70 countries, but for us, it works and it supports a-sync work. It means that there's things going on 24 hours a day. It means we can hire staff anywhere on the globe. You know, for most roles, it doesn't matter that they're in a specific location. You know, that helps alleviate the problems said earlier by Kalle that staff shortages and so on. We don't have to look for somebody who is based in a particular area.

Adrian (45:00):

We can look globally. So the flexibility that gives you as a worker is pretty compelling, so...

Kalle (45:10):

I would say that remote-only… transforming a corporation or company to remote-only, it's the same amount of work than doing an Agile transformation, or an organization change in general.

Adrian (45:20):

Yeah, possibly more to do it properly. 

Kalle (45:26):

Yeah, I've heard from few companies that have written in their newsletter that we are now remote-only company like GitLab. So, did they change anything? No, no, no, no, no. I'm like, okay, that's not going to work. You're going to be in the office in half a year. 

Adrian (45:41):

Yeah, I think GitLab had the advantage, it was that, you know, right from the outset, that was the way the company went. And so it's evolved and it developed practices. You know, gradually over time iterated on these practices. And so it's effective. So I think if you are going from a purely office-based organization, you do really need to think about it and look at it. 

Kalle (46:05):

We're going to see a new job title, which is going to be a Remote Consultant who's going to be like a coach, but he's going to be, oh, it's a Remote Coach. 

Adrian (46:20):

They do exist. Yeah. 

Kalle (46:23):

Yeah, we're going to see a lot more of that in future if companies keep doing it. I'm skeptical with like, everybody has allowed me to bear, I'm old as much as I want for that, lasted seven years already. But we have not been remote-first of course, because we have customers that require us to be on-premise, etc. But I was skeptical after seeing like all kinds of things, so that already been a problem in management. And how do we do management in those things and how do we do these customers? I'm skeptical how a very big company can go fully remote, for example in long term. Like they've done it now, but when it's possible to be in office, it's going to be very weird. Can they keep it up? Because communication culture is so different. 

Lauri (47:04):

I wanted to have one more question on the substance based on your conversation. And then, I will give Kalle the last question. Integration, you said before that there is a difference between best of breed and platform in the sense that in best of breed, you integrate products with one another, and the platform model you integrate the other products that you use besides the platform to the platform. Now, I remember a few conversations in the past where our podcast guests have said that this is the era of integration innovation. So what's your take on integration and to put it bluntly, is it open APIs or is it an integration platform? So will you take an integration platform where you take those disparate products, integrating them into the integration platform, which then talks to whatever that toolchain as a platform is? Or is it going to be okay, let's have open APIs everywhere and integrate everything straight into the platform product? Just to make it black and white for you.

Adrian (48:05):

Yeah, I think there's a bit of both, but predominantly the open APIs. Say like the way that integrations often happened in the past would follow the tool chain. So you'd have a tool for doing planning. It would do something and it would hand off then to integrate with a tool for doing the development and into another tool to do the CI and another tool to do maybe the security. So you're almost changing tools together. Whereas, you know the approach within platform orientated is each of those tools can either use open APIs, that GitLab offers to integrate into the platform. Or obviously, we're an open-source platform, you know? You can actually go down to that sort of level if you want. And some partners and some will want to do that. They also want to build integration at a deeper level than provided. But for the main, I would say that, you know, really using our opening APIs is the simplest and most straightforward way of integrating these third-party tools. 

Kalle (49:20):

Yeah, I would say open API system is the way to go forward. And [unclear 49:24] that you need to support but you shouldn’t approach it from that. You should approach from API first. 

Lauri (49:30):

Yeah, and some third-party products, GitLab will do the integration. You know, we same them as key. So things like, integrating with HashiCorp Vault, for example. That's something that we provide because we see the benefits and the use cases for doing that. And in other cases, third-party vendors will do the integration. I've talked about, you know, security and the benefits, the work flow benefits of the platform. That doesn't mean to say that you can't use existing security tools. So we published in effect an interface that would allow a third-party security vendor to produce their output in a way that would then be used by the GitLab workflow. So if you've got your favorite security tool, you know, does a great job of that particular type of scanning and you want to maintain it, then fine. But being able to take the output from that security tool and bring it in consistently with all of the other types of securities, you know, scanning and vetting that's going on adds real value. And we've seen some key security vendors doing that. They've developed and provided the integration for their particular products. So they fit in to the overall, you know, GitLab security process from a reporting and a vulnerability and a remediation perspective. 

Lauri (50:53):

So that brings us to the last question. And as I said, I'm going to give Kalle the honor to handle that question. 

Kalle (51:00):

Metaverse, what are your feelings? Reads in my paper. Facebook came out now known as Meta. Came out with their concept that they are going to be a Metaverse-first company. And I have my doubts about Facebook's Metaverse started, but I have feelings about few others. And I feel GitLab is kind of in a place where they will be a Metaverse competitor, if they would go there. So I'm interested in hearing what Adrian's views are. 

Adrian (51:30):

What do we mean by Metaverse? I tell you there's really exciting aspects to it, but I also see sort of dangers where virtual and reality get mixed up and people get drawn in and start to sort of not understand what is virtual, what is reality? So from almost an addiction point of view, you can get sucked in and lose yourself in that, which in some ways is exciting and interesting, but in other ways, I think it’s potentially dangerous. 

Kalle (52:10):

I think the same has to be said for game consoles and PCs and so on in history. So I think that's completely valid concern for all of us. Why I actually started talking about Metaverse and GitLab, etc. must be because 1. I know, just saying that's like Facebook is not the number one in Metaverse, Microsoft is. And that is because Teams platform is a cooperation platform between corporations and corporation-discussion platform. So if they would incorporate just the headset to it, it would theoretically be a place for a corporation to jump in and have a Metaverse theoretically. So that was where I was like, but GitLab is kind of the same thing for developers if we look at it. So if you incorporate it, I I'll take my royalties at that point. 

Adrian (52:58):

We are open source, Kalle.

Kalle (53:00):

I can write it, yeah.

Adrian (53:02):

What are you doing this weekend? 

Kalle (53:05):

Quick Metaverse, we are coming, yeah. 

Lauri (53:08):

This has really changed my point of view of Metaverse when I think about concept of screen time. I just observed my own boys in the living room, playing games in the virtual rarely using Oculus glasses. And when they are done with their gaming sessions, they are like soaked in sweat and they're perspiring like mad. And the question is, does that count as a screen time? Or does that count as an exercise time? And therefore, if they like doing it and they get physical exercise, do we have to put boundaries on how much per day they can do it? I think about it. It's quite fundamental question. Do you need to put screen time on physical games on Metaverse?

Kalle (53:50):

We get to another question, which is then again, like, so I used to work in the game industry and I still follow it quite a lot, which is kind of like what happens if those games are free to play full of ads or corporate calendar. So then like you are a client of still exercising and we are not tracking it, but at the same time, you can't be brainwashed because you're in a screen. So how do parents keep track of that? If we go into that discussion, then like, this gets really, really deep. 

Adrian (54:20):

And I think the 3D and all the visualization, you know, is just so mind-blowing really as to what's possible. I've been around a few years and before your time in the games industry, Kalle, there was a… on Unix, there was a game called Rogue, which goes back to the early 80S. And it was a Dungeons and Dragons type game where you have to wander around levels and find potions and avoid trolls and umbers. And it was totally and utterly addictive, but it was on a green screen. It was just dots and dashes and asterisks and things like that. But you could get totally addicted to it. Well, I did get totally addicted to it. But if you then sort of look at, okay, well that was a green screen, look at what you can do today with the visualization, how much more addictive that must be, that that's sort of where some of my concerns around where this could go is. 

Lauri (55:20):

This has been an awesome conversation. Thank you very much, Adriana and Kalle, both for joining the DevOps Seminar Podcast. 

Adrian (55:28):

Thank you for inviting me. 

Kalle (55:30):

Thank you. This was fun. 

Lauri (55:33):

Thank you for listening. As usual, we have enclosed the links of the social media profiles of our guests to the show notes. Please take a look. You can also find links to the literature referred in the podcast on the show notes, alongside other interesting educational content. If you haven't already, please subscribe to our podcast and give us a rating on our platform. It means the world to us. Also, check out our other episodes for interesting and exciting talks. Finally, before we sign off, I would like to invite you personally to The DEVOPS Conference happening online on March 8^th and 9^th. The participation is free of charge for attendees. You can find the link to the registration page from where else? In the show notes. Now let's give our guests an opportunity to introduce themselves. I say, now take care of yourselves and see you in The DEVOPS Conference. 

Adrian (56:22):

Adrian Waters - I'm a Solutions Architect at GitLab. I've been in the industry for many, many years, originally as a developer and then going on to manage both the development and the Ops side of, you know, some large-scale projects.

And then for the last 10 years, I've really been focused on the vendor side in terms of things like version control and CI, and DevOps, as it's now become known. And in fact, looking back, I was practicing and promoting DevOps before it was a term. So it's been a natural place for me to end up. I'd been in GitLab for just over three years and work in both initially with our enterprise customers and helping them. And then more recently with, you know, our great partners such as Eficode. 

Kalle (57:10):

I am Kalle Sirkesalo. I work as a CTO of Managed Services for Eficode. I've been here at seven and a half years now. Being around all kinds of things, seeing multitude of corporations, 24/7 for seven and a half years. Working on operations of big customers. I don't know. You can find me in LinkedIn if you want to know more.