DevOps Decrypted: Ep. 13 - All things DevOps, MLOps and Chatbots feat. GitLab

Welcome to DevOps Decrypted! This month, guest host Ryan Spilken joins the conversation with Jobin, Jon and Rasmus. The group talks about a different kind of Ops – MLOps, specifically – and how you might build a chatbot with it.

That’s all in a special interview segment with Péter Bozsó – Channel Solutions Architect for GitLab. Péter tells us all about his role in DevSecOps and working on the new MLOps features within GitLab.

We also talk about the Atlassian Unleash event, where Adaptavist announced a new DevOps platform called Venue DevOps, and we cover all the biggest news from the event.

Hello, everyone, and welcome to DevOps Decrypted.

You might be a little confused, considering that you're not hearing Romy's voice right now, and that's completely understandable.

My name is Ryan Spilken, and I'm filling in for Romy today because, basically she's lost in the jungle. So who's helping me find the way out of the jungle of DevOps? Well, I'm joined today by Jobin Kuruvilla, Rasmus Praestholm, and John Mort. Gentleman. Hello.

Hello! Hello!

Hey, Ryan!

I am very sorry for not being Romy. You know, you're gonna have to work with me today.

It is a big deal – but I think we're okay…

Well!

I appreciate that alright, Jobin. Well, the first thing that we wanted to look at today on DevOps Decrypted, was Atlassian Unleash – who let the dogs out exactly in that case – but the biggest dog that they let out of the they let out on, at least it seems, to be product discovery.

Why is product discovery newsworthy, Jon?

Well, so we've been using product discovery internally since we could get on the Beta, and it's actually a product. I'm quite excited about – or the problem area that I'm quite excited about that being a good solution.

Because I feel like this kind of software and industry. We’re optimising pretty well the delivery, the delivery aspect of software and things. And but we're not necessarily delivering the right thing like in, “was it worth it? What did it meet the customer's needs?” I see that as being a really big problem. And in software, kind of like takes some steps towards solving that and meeting that customer need much more. This much more visible sort of thing. So I think I have high hopes for the product, and we've enjoyed using it as well. It's been really useful in our internal usage.

So, Jobin and Rasmus might disagree. They might say, Well, I don't know if we've gotten delivery down pat just yet!

But do we think that… How does your product discovery help teams find out what the customer is really looking for? That's the thing that doesn't quite make sense to me.

Yeah, I mean, I was actually going to the announcement. I think the biggest thing that attracted me was, you know, gathering customer insights.

That's the highlight in that particular part which is very expensive to know what the customer wants right? So I think that's about that. I am very keen…

Obviously, as Jon said, you know the DevOps, and that everything that we are doing DevOps sent in aside doing to get customers deliver something. I think things are getting much better. But what should we tell you? What is actually the product there?

That's what the customer is important, gathering that customer insights that will help you get there.

It makes me think of value stream mapping, which is a good thing.

And even though, of course there's always more we can do in just kind of like general DevOps and tooling and optimising so on… I do very frequently come back to thinking that, hey, wait a minute – we gotta also remember the soft things, the one down just about tools and delivery, and so on. The people and the process and the product. So while I may not be particularly familiar with this thing, I you know, pumped into some other ideas, gathering pieces of software. And it's good to have, and this can only be a good thing in that, in that sense.

From the customer's perspective, is the data collection side transparent? Is it something they have to opt into? What does that look like?

…I don't know.

Yeah, Same here. I'm actually looking forward to using it and seeing what happens here. I mean. Another thing that interested me was, you know, the discoverability. So it talks about, you know, integrating delivery and discovery. So yeah, I'm. Definitely hoping to try it out and see what exactly they mean by that.

One of the things that it does do, and I think does do pretty well, is it makes the discovery element something that the whole team can participate in. It's not just the per-view of, you know, like the product management organisation or the or the user research and things like actually, the entirety of the team. And anybody who's got insights can provide insights. You can vote on things, you can apply risk assessments... Look at, you know how much impact a feature would look at effort analysis, and those sorts of things.

So it kind of I think I really like about it is that team inclusive, being on things. And so, if you have an insight from a customer, you can, you can just attach it to the ticket, that represents that idea and just go use it. And because it's Jira and they're all modelled as issues, all of the rest, all of the other Jira stuff just works with it. So your reporting dashboards and like links and things, or just it all just works, which is kind of powerful.

And Ryan, you might be thinking, Why? Why can't we answer some of these questions? Because, you know, this product was actually in Beta, it just became generally available, or it is becoming generally available just now, and that's what I'm lost in unknowns in the Unleash event.

So yeah, I guess I mean it's finally getting into our hands.

All right, all right. Well, we'll keep an eye on product discovery or the and report back if there's any interesting developments there.

Other news that Atlassian is really pushing right now, coming from Unleash, would be Jira Work Management for free, and new templates.

I'm gonna say that's marketing.

I'm just gonna say it. Is that… is that controversial? I don't know.

I mean they’re getting something for free. I mean, I'll take it?!

That's fine. That's fine. They've also released some new templates. Did any of the new templates, would they have appealed to our DevOps listeners? Is there anything in there for the DevOps practitioner?

So probably. Yeah, there's some value stream management templates, and there I don't know. I mean, I'm seeing templates around operations… workflows, permissions, schemes – that's all normal.

So, we have to try it out and see what exactly it does.

The Adaptivist group has some news dropping at Unleash, too. Am I right?

Yeah. So we did. Actually, went ahead and announced a new DevOps platform called Venue DevOps – it’s a new business unit within the Adaptivist group, which will be focusing on DevOps, tooling, and DevOps as a service. More on that to come out soon. There is a website out there. It is called Venue DevOps – one of our participants, Rasmus, is keenly interested in that.

There's a website out there. If you want to go get an early preview of it.

We'll include a link to the website in the show notes.

Rasmus, tell us a little bit about Venue – so, you are designing back-end diagrams and the nerd stuff for Venue?

It really goes back to that whole bit about the soft stuff I mentioned earlier in that anybody can give you a marketplace. That spins up applications or connects one tool to another tool.

But I find that the value is in what can we do to better support and templatize the soft stuff.

And how can you do that with people and processes? Well, we’re about to find out…

Just to put that in perspective. So if I am the customer who is coming to Adaptavist, so when you basically offer me not just the DevOps tooling, but also, you know, maybe templating around the people and the process and things like that. And you know the services around those tools – everything.

Yup. We have sort of been bandied around the term DevOps as a service, or DevOps tooling as a service as an interesting contrast on, well, for all these platforms and marketplaces out there, are you actually getting DevOps, including the cultural pieces, some sort of material that'll help you encourage your fellow coworkers on just adopting more same practices and helping discovery visibility inside the company. All these kinds of other things. So I'm hoping that's where this is going to make more progress.

And to completely translate that into the customer’s language, “I can finally focus on the business problems and not worry about DevOps and the tooling.”

Yup DevOps is going to make itself disappear in a sense…

Work so hard that we don't get hired again. Wait what? Well, all right…

And alongside our talk about Venue, Alexander Post, The managing director of venITure, spoke about how to automate key result reporting, using Jira and quantitative results. So okay, our measurement… Does that fall into the DevOps world?

I mean anything that's a metric, Can.

I would say, absolutely, yeah, I mean companies, some… And you know the way they can keep track of the progress is using, okay, as you know, measure the progress right? So I haven't seen the talk but you know it sounds very interesting to me. And obviously it definitely falls on the DevOps realm. So I should probably go and take a look at that.

Yeah, it's something that Alexander’s helped a number of organisations in, that. And then we're like we were talking about Jira product discovery, is that, making sure that we're building the right thing – make sure we're going in the right direction, and that we're aligned on things, so that that's very much in the DevOps mindset.

We are also going to be at the Cloud Expo on 8 to 9 March, and that's in London. We'll be there on the GitLab stand, doing some demos – gentlemen, tell us about that.

It's gonna be an interesting event. So obviously, Cloud Expo is one of the biggest events around Cloud and DevOps in general in Europe.

This time we are going along with our strategic partner, GitLab.

GitLab obviously does a lot of things in that area, and there’s going to be at least 2 or 3 demos from the GitLab stands – one of them will be around our deployment of kubernetes, using the native integration GitLab has with kubernetes, and I will probably be doing that – that's the plan as of now.

So I'm going to be in London if anybody wants to come and say hi in the GitLab booth, I'll be there. Along with me, 2 other folks, gentlemen from GitLab, will be presenting different topics. I think one is around shifting left, and the other one is around security insights within GitLab.

There's a lot of interesting topics there. Stay tuned!

Okay. So, listeners, if you are going to be at the Cloud Expo 8 to 9 March this year. Go up to Jobin and say, “DevOps Decrypted sent me!”, and he will hook you up with all the merch he's allowed to give out, okay?

Absolutely – yeah, I can do that!

Turning our focus to DevOps in the news, Google has seemingly released a tool that is extremely good at wiping off market valuation.

It's called Bard.

From a DevOps perspective – what happened there? What a disaster!

So I think this may actually have nothing to do with DevOps, but something that kind of justifies Google's caution. In the first place.

The way that this perspective rolls in one way is that, OpenAI, as an almost relative, unknown, nonprofit, small thing that came out and over, and just like, boom, suddenly this ChatGPT thing came out, and it just went viral and went crazy. And a lot of people are happy to sort of glance over the drawbacks it has about bias and all the kinds of things you can make it do, because I mean they're new. It's fine. It's fine

And part of the reason Google has been so reluctant to release, and then, just like, put everything out there – because they've had to take behind Bard for years – it's because whenever Google presents something, it gets viewed in a very specific way.

And that's exactly what happened when Bard made a, I understand, kind of like a trivial or easy to make mistake, for you know, a model like that.

And then it's like, oh, no, it's the end of the world. And, like Google is doomed, and all these kinds of things.

So I think it's a storm in a teacup, and we will see how Bard actually can handle going up against ChatPT or Bing sometime in the coming months, but we can't even get to it yet. So on like last week, we can't make it, you know. Make the title for this podcast also, which is a bit of a pity, but… oh, well.

I think also there's a quality issue here – like, surely, if you are going to put out a demo, you'd make it right… you’d spend a bit of time and do a bit of a quality test on it.

I think it's all about the data, right. I mean, we talk about machine learning, and you know there's a lot of data around, and it's only as good as the data.

I remember that was the case study about. I think it was a hiring process at one of the universities in England…

So basically. They used machine learning to, you know, start sorting out the resumes. Now what really happened was obviously they were taking into account the past hiring, and you know that was what was considered.

There was definitely a lot of bias involved in the past when people were hiring in that university. And what happened was the data was actually validating that by. And you know.

Unfortunately. The machine learning algorithm picked up that bias and you know, used that data, and obviously, and you know, started using the same bias in its hiring process. That's what's going to happen. So it's only as good as the data.

I mean. That reminds me of the time when I believe it was Microsoft that released a chatbot that within 24 hours turned into a racist scumbag –

Exactly – that was another one. Yeah, I didn't want to mention that one. Because…

Well, that's what I'm here for Jobin – don't worry about it!

Yeah, I mean, I have actually seen a video where people like, use ChatGPT off leaning left. So, that's coming! It's only going to get worse… What's interesting to me was, you know, ChatGPT only takes into account the data until 2021, whereas Bard is going to look at the entire Internet, and you know, gather information from all around the Internet – so I'm curious how it's going to behave when different questions are us depending on what's what's latest happening in the world?

Well, as long as Bard can't predict the future, I think we're still safe. I think we're still pretty far away from the Skynet scenario.

But tools like this: tools like Bard, tools like ChatGPT, they have to have a fairly sophisticated back-end, supporting them, and there has to be some DevOps overlap there. Right?

Yeah, absolutely. I mean, I I and that's where people call it MLOps, right? So machine learning opps!

And it just so happens that Rasmus, Jobin and I got to interview GitLab’s Péter Bozsó – over MLOps. Let's take a listen to that interview now…

And now, Jobin, Rasmus and I get to welcome to DevOps Decrypted, Péter Bozsó – Channel Solutions Architect for GitLab. Péter, welcome.

Thank you Ryan. Hi everybody. Good to be here.

Hello, Péter.

Hey, hey, Péter, you focus quite a bit of your work on DevSecOps, but you're not necessarily here to talk about that.

We're going to dive into MLOps in a second, but before we do, tell us just a little bit about your work in DevSecOps – what do you focus on in that area?

Usually, I would say it's not even my personal focus, let's say.

So it's in the last couple of months or almost, maybe years, DevSecOps is the overall strategy for GitLab.

Right?

So, I would say it's more correct to say that every solution architect at GitLab is very strictly focusing on DevSecOps right now.

And we are different in kind of like which particular part of the security, we are more narrowing into or a certain technology or a certain partner technology, this kind of stuff.

But I would say DevSecOps is really in the mind of everybody right now at GitLab, so that's like top of the strategy for us.

And yeah, I, I am on that as well.

I am approaching this whole topic more from the developer side. So like the Dev part of DevSecOps, because my experience is more on the software engineering part of the whole Dev thing. So, I usually looking at the security from that point of view.

So Péter, tell us more about MLOps, and how likely is it different from DevSecOps or DevOps in general?

I mean, everything is Ops these days!

I think we even had a blog post predicting the future and you know, we typically we actually put that headline in there.

Everything as Ops!

So how is it different, what exactly is MLOps?

Yeah, I think Jobin, when you put it right here, everything is getting Ops – we even have a thing at GitLab called IMOps.

So yeah, everything is Ops now… MLOps I would say I like to look at like I think MLOps is essentially a superset of DevOps or DevSecOps.

So in my point of view, MLOps have the exact same challenges and issues and difficulties as DevOps and a little bit more even on top of the, just by the nature of machine learning, right?

Because in traditional software development, so DevOps or DevSecOps, the logic, the main piece of deliverable that you do is basically the source code, Right?

That's what everybody is working on.

That's what you review, that's what has the bugs or that's what that's what drives your business and MLOps is that and a bit more right?

Because in MLOps you have its model ops right?

Or machine learning Ops or or whatever, how you, how you, how you say it, but let's put to the stick to the machine learning ops and in that case, what is a machine learning model is essentially right?

It's data and algorithm which is called and some parameters essentially this is what makes a model.

So source code is there definitely just like in DevOps like in normal software development, but you put the data there as well and the parameters and these three things together brings a lot of challenges on their own.

So I would, I would say something like that.

So I also had, I thought about this earlier and how do you contrasted to DevOps and came up with the idea of looking at embedded hardware development where you have some actual physical pieces involved in the process.

How do you speed that up?

How do you DevOps exactly take a board and put it into the test stand just with MLOps?

You're dealing with a model made up by data and so on, but it's still not kind of one of your traditional artifacts in that sense.

Yeah, absolutely.

I think the the similarities is certainly there, it's both of them are DevOps extended, so to say with their own challenges.

So, can you talk a little bit about some of the challenges that you experience just focusing on the data sets? Interfacing with the code itself?

What we usually see inside GitLab at our customers is that data is usually very big data sets.

Right?

8:31

So it's much bigger than just source code.

And that's what that's what also makes it very difficult to version.

Right?

Because source code, it is just text files, you can compare you can see even moving the data with it is pretty, pretty quick. Right?

But doing that with data, it has its own challenges.

So doing that with traditional DevOps tools is very, very difficult just by the sheer amount of the data that you have to move in between your local computer and the server.

So because of that we at GitLab looking at what the industry is doing and trying to cooperate incorporate some new features into GitLab to accommodate these needs, mainly, mainly the handling of the data together with the code.

Someone just like, okay, I have my source code in the Git repository in GitLab and I have my data in whatever storage solution that you have.

So we are trying to put all these in the same bucket with the parameters.

So that's what makes up the model and put the whole thing together on GitLab.

So it can, it can be one package essentially one unit of data or machine learning or models basically.

Okay, so if I'm curious because I have to link everything these days to ChatGPT, if I had infinite money and was actually smart and I said I'm going to make a ChatGPT competitor… What do I do?

Like what's the first step?

Is it something just like you read some blog entries and figure it out or are you going to put a nice big black button somewhere that just says like “create MLOps thing”.

Certainly you need to read a bunch of blog posts. I would need to read a bunch of blog posts to start on ChatGPT.

That's for sure – a couple of textbooks!

But yeah, on the, on the side of GitLab, so it looks like that.

Currently, almost all of the MLOps features that we have are either in private beta or will be in private beta soon, so in the currently available version of GitLab that is on GitLab.com or what you can install on your own servers, there are basically two main features that can be relevant for creating something like ChatGPT.

So working in the machine learning space one is actually not that relevant, but that's something that's, that's there, that's usable for a long time now is the Jupyter Notebook support, support that we have and a lot of messy learning folks are using this.

So Jupyter Notebook is essentially, you can think about such a thing like a document which is very interactive.

So you can have their text, some code, some algorithms and you can present some data experiments in such a document.

So that is first class in GitLab right now.

So it works like what I mean by having first class support for Jupyter Notebooks in GitLab, is that you, when you are doing a code review as part of a merge request, you can actually render the Jupyter Notebook because Jupyter Notebooks are just JSON files, essentially.

So you can compare the JSON but that's not really useful if you want to understand what happened.

So what I can do, it can render the page and you can actually compare Okay, how the outlook roughly will look like that's something that could be useful for machine learning.

Not certain, not strictly just for stuff like ChatGPT or something like that.

Like a really smart chat but what we are having and what is currently I think let me check my notes.

Yeah, it's still in this dogfooding phase.

So we are using internally but it's it will be in private beta soon which is the experiment tracking feature of GitLab which is I think would be the most useful for developing something like that.

So experiment tracking is essentially you can think about it.

It's very similar to a GIT repository in terms of like storing the in progress stuff so to say so the code, not the not the finished artifacts, but in this case it's it's storing machine learning experiments which is as I mentioned before, it's basically data, the algorithm and some parameters together.

So that's something that could be really useful if somebody is more familiar in this space about the tooling.

It's essentially an ML Flow back and integrated into GitLab.

So ML Flow is a tool which you can use.

It's not by GitLab

It's a I think it's an open source application actually an ML Flow is basically something that you can either host yourself or you can use the SaaS version and it's a back end where you can store runs of your experiments.

Right?

So you are running the experiment on your local computer with your machine learning algorithms and data and it will store the different runs in the server.

And that's something that right now or not right now, but soon you will be able to do in GitLab as well.

So for example, if you are training algorithm an AI, something like ChatGPT.

So the machine learning model for such an AI that you can do on your local computer.

But the end result of these experiments end up in GitLab, essentially, and everybody in the team can see okay changing the data set or changing this parameter will end in this result in the model in the resulting model.

So, that's something that you could use.

And another feature which is still in just plan planning phase essentially.

So nothing has been developed for that is modern registry which is essentially package registry just for machine learning models.

So it's like a specialized version of our existing feature which is package registry just for machine learning models.

That's a lot of information to unpack… and I just want to make it a little easier for our listeners.

So, what we're saying is there is a lot of features that's not currently there, but in the beta version, that supports the ML workflows, and basically you can start using that in the near future in GitLab. And if you want to create a competitor for ChatGPT… and I probably wouldn't read a lot of books, I'll probably go and ask ChatGPT itself – but anyway, once you figure that out, we can then go use GitLab as a tool to do it.

That's what we are saying.

Yeah, pretty much. That's what I was saying.

So you did mention a couple of features already – called out the experimental learning workflow and how we can use the different models within GitLab Pipeline. So what is going to come out first? What's going to be the biggest feature that's coming out in the, in the near future?

It's 100% the experiment tracking feature.

So the one that you are using for your so you are using your local computer to run the actual experiments but the result of the experiment is ending up in the server.

That's what is coming.

And this is, as I mentioned, it's essentially a re-implementation of a back end of this tool called ML Flow but it's not like a 100% free implementation.

So ML Flow does much more than just this.

This is one feature of this open source tool which we will incorporate.

It will go into private beta, so interested customers can give it a try see how it fits into the overall get lab workflow and based on their feedback, we will either implement more features for from ML Flow or we will basically branch out and implement new stuff based on how it better, how can it better work together with the already existing GitLab features.

But the beauty of this is that we are only reimplementing the server part.

So ML Flow works like that.

You basically have a library in your own machine learning code.

Usually python code.

And that library is the same.

You basically just telling the library okay, upload this, not to ML Flow, but GitLab.

So that's all you need to configure and it works completely transparently.

So that's why we choose this path because we saw that many, many people are using this ML Flow already.

So it's like, it's much easier to switch if you don't need to rewrite all of your scripts, right?

And everything that you've done so far. You just use the existing tool and just switch out the back end in the picture.

So, and to clarify for the uninformed such as myself, when you say an experiment is uploaded into GitLab, is that the, the artifact that is coming out of a machine learning run– what exactly is an experiment?

It's literally, that's an experiment is made up of the algorithm, which is literally source code, usually some python code.

The data, which is a big, can be a big data set, a small dataset, whatever and a bunch of parameters.

So basically you are saying you are, you are telling the model is basically the code, you are telling the code Okay, Crunch this data with these parameters.

That's an experiment and that will you can imagine it will split spit out a model, a model candidate, that's one experiment and then you are a data scientist on your own laptop running these experiments with essentially you change either the data set either the code, either the parameters sometimes the only thing you change are the parameters right?

Everything is the same.

Change the parameters.

And you will see all of these experiments showing up in GitLab, you will see the result, and the result is essentially the model itself and some data about the success of the model which you define yourself like Okay, this is the, this is the metric, metric is the right here.

The metric that I'm looking for and you can actually see, okay, it improved based on my fiddling with the parameter or or didn't And then I can just say that okay, I run this experiment three times right with different set of parameters.

Okay, this was the best let's go with this one.

I will; I want to keep this one the result of this one because this actually improved the success criteria of my model.

That’s the whole workflow essentially with ML Flow right now and will be the workflow with GitLab as well when this feature comes out of so to say dogfooding phase.

Okay, so speaking of experiments then, can you integrate that approach with the current way, get lab handles environments and sort of be able to promote an experiment into particular environments that use the data for something?

Not yet.

But these are exactly the kind of discussions that we're having with the customers right now.

So that's why we choose this approach like okay just implement this very basic or not basic but core feature of ML Flow and these, these are exactly the use cases but for example there's a use case which you already got from our customers.

Like, let's imagine you have a merge request right for your machine learning model, and you would like to see in the merge request view if the changes that the person who created the merge request the changes that he or she made to the model basically increase the, improved the metrics or not.

So like, like a widget like currently what you have with the quote quality widget that you can see in the merge request, something like that we would like to integrate into the core Git workflow.

So these are exactly the use cases that we are just thinking about.

Okay, how can we make it more less?

Like just a siloed feature and more like part of the whole workflow.

Neat!

How about testing? So what is happening on that side of things? How do you test these experiments from within GitLab as part of the pipeline?

Is that something that you can do today?

So you mean like distributing the models?

So you mentioned these sorts of rate for experiments? How do you calculate that? And you know, make sure that you haven't introduced that…

Ah yeah, so that's on the side of the actual data scientist who is creating the experiments.

So they based on the algorithm and based what they want to achieve with the actual model, they define these metrics.

So it's more or less part of the python script that is crunching the data and outputting the model.

It's outputting these metrics as well as part of this experiment.

I see.

And one of the major features that will help teams on board is auto DevOps within LitLab. So are you planning to introduce any of these pipelines as well as auto DevOps?

That's something that I have no information about.

But actually also a very great idea because I personally see a lot of my customers and partners just going with auto DevOps initially.

So yeah, that would be actually really nice.

Just like saying, okay, this, not, not even you could do it the similar way that auto DevOps works right now.

So you can just say GitLab will recognize that this is a machine learning project and just try to figure out auto DevOps in a way that Okay, this is like a pipeline for a machine learning project.

That would be nice.

Péter, you can have that one on DevOps decrypted. Just tell ‘em Jobin sent you.

One thing that is so interesting to me when using GitLab as a tool was, you know, small improvements that actually make use of machine learning in the back end, like, for example, when you create a pull request, it automatically suggests the approvers that can work on the pull request based on who is on vacation, who is not, who had been reviewing similar pull request… it's a simple feature but very powerful because you don't have to then consciously go looking for reviewers and other features, and GitLab like this, you're consciously adding using machine learning in the back end.

Yeah, there are some stuff that is brewing but currently, that's the one that's already in the product.

That's what, what is, what I would really usually when customers ask me, okay but can you give me an example how machine learning is used and that's what I point them at, basically what we have is a product team at GitLab who is working just in this ai related stuff that can be used as part of GitLab and one of the most at least for me most exciting feature that more or less almost everybody in this team is working on.

So basically the the experiment tracking, which I mentioned is a single engineer project – we have a concept of single engineer engineering teams.

So like a team which has a single member right?

The point of that is that one person can iterate much faster on new stuff until this thing gets into a certain level of maturity and at that time a product team can take it over.

So that's the experiment tracking.

But we have another feature which for me is very interesting is the I think we call it right now AI Assisted Coding or code writing or something like that.

So basically, it's a competitor to Github’s Copilot, right, let's say it's GitLab’s answer to that.

So that's what most I would say 99% of the engineering effort right now on the AI space inside GitLab is spent on that, and that's what's coming, and that will also be part of the, so we have this new web ID… If some of you haven't missed or have missed the last update to GitLab.

So that came into beta, which is like visual studio code integrated into.

So now if you edit code in the browser it will be VS Code and this AI-assisted editing will be part of that experience.

I have no information about if it will be available on your local ID.

But honestly, I would be very surprised if it won't be.

But these are the areas that are getting the most focus from us right now.

Yeah definitely like the new ID, and they have had really good positive feedback about that.

But basically what you're saying is GitLab as a tool you can use it for machine learning development but at the same time GitLab itself is implementing a lot of it is that uses a part of machine learning behind the scenes and making life easier for developers.

Yeah, absolutely.

And the most important part I think is the MLOps features that we are putting into GitLab, we are using them as well.

This is always true about GitLab – we use GitLab to develop GitLab – but the MLOps features, for example, this experiment tracking, is right now being used internally by our teams before it's going into private data.

So usually that's what we do.

We try the stuff ourselves if we like it, yeah, then we do the easy for our customers if we don't, and you just get over with it.

Good old dogfooding!

Yeah, yeah, yeah, absolutely, absolutely. I'm reading my notes from a GitLab issue right now… So, come on!

So what is coming up next? What is in this space that GitLab is not telling us yet?

Not telling…

That's it, if there are something like that, even I don't know about it. Usually it's… our own issue board is open, right? So apart from the security vulnerabilities of the GitLab project itself, is open on GitLab.com – so it's as much open to everybody as it's open to me.

Yeah… The biggest thing is really this ai assisted code editing, I would say.

Péter Bozsó, Channel Solutions Architect for GitLab – thank you so much again for joining us on this episode of DevOps Decrypted.

Thank you very much guys. Pleasure is all mine.

Listeners: what do you think of MLOps? Let us know in the comments section on YouTube or in your favourite podcast app.

Once again, thank you to Péter for taking part in that interview. I learned a whole lot, it was super interesting!

All right… for our last segment. I just want to know from the 3 of you… What's next? What do we need to be concerned about? Jon Mort – what do I need to be keeping in mind when I'm going about my DevOps practitioner day to day?

So something that I’d love to talk about a little bit more on a future podcast is the infrastructure from code as an evolution of like, the infrastructure as code. And I think that's really exciting to be looking at. I think that's a really novel take on the things, it's about reducing the friction to get things into production and things that I think that, you know, are really really interested in that.

I thought I understood infrastructure as code, Jon, infrastructure from code – that's blowing my mind. We'll have to talk more about that another time!

Rasmus, what else do folks need to be concerned about?

So I think it'll be interesting when we have more than one big chatbot bought to see what happens when they kind of go up against each other, maybe even literally – like what happens if you have ChatGPT have a discussion with Bard?

I mean, that it's not going to explode the universe just yet, but it sort of also links back to… We have these amazing tools now. We can have robots, you know, write up real estate listings and Amazon entries and things like that. I hope that it will also lead to a point of retrospection where you sort of like, well, wait a minute: it used to be that, like real estate listings that took a lot of extra steps to really make their entry look like shiny and attractive, and so on, managed to make more sales.

What happens when anybody can do that with the press of a button?

Will we just have bots putting out the fluff and other bots that'll read the fluff and summarise it for you?

…I think, the Internet's just going to be bots talking to each other before long…

One of the things about that is, I wonder if it can help us make more meaningful discussions.

I don't have a whole lot of hope here. It really will probably just be. But it's talking to bots on the Internet, but maybe we can get to the point of thinking about it. You know, why don't we just not put all this subject-to-fluff around things and just get down to the objective details?

So we don't need all this stuff now that we can do it with the present button. Let's just get back to simplicity.

Well, Rasmus, maybe the machines will decide that the humans are the extra fluff… and that'll be that.

Jobin, what's the future hold? Look into your crystal ball. Tell us what you see that people need to be thinking about coming up.

I mean, I was just thinking about machines deciding, you know, humans being the fluff…

That's a lot of positive with you there… I mean it's very difficult to predict the future. But with all these AI bots coming out, you know, one can't stop thinking about how people will be using it in the future.

Rasmus talked about, you know bots talking to each other, I did remember back in maybe it was 2015 16 when self-driving cars were becoming one huge thing. I think Musk and everybody around him both projected this idea of, one of the biggest advantages is going to be, you know, cars can talk to each other, and so the accidents will be much, much lesser, because, you know, they are already aware of where it's going, and it's going to be a wonderful world.

But the truth is, you know the self-driving cars, that's not a reality even today. 2022. Right? I mean, it was supposed to be in 2016 to 2017? That hasn't happened yet.

So I think we have a long way to go. I mean it. It's great – ChatGPT adds a lot of value. I like it. I personally use it, but it's all going to be how people are going to use it, and you know it's going to take a lot of time before bots take over control of the end of the world – that's not going to happen… not when we are alive… I wouldn't say that, but probably not in the next 5 years, 10 years.

I mean, I know it's off-topic. But clearly, you haven't seen the Boston Dynamics Robot.

I don’t want to see it – I think I’ve already had enough positivity for today!

I’m kidding, I hear you, and I think you're right – I don't think robots are coming yet.

And on that note, that's it for this month's edition of DevOps Decrypted. Thank you so much for listening.

Listeners do us a favour – we need your help.

We want to hear from you. What do you want to hear about in the world of DevOps?

What are you interested in?

What future technology do you think could take over the world instead of ChatGPT?

Let us know!

Please review and comment on our podcast, wherever you interact with your podcast – be it Spotify, Apple Podcasts, Google – whatever! Review, comment, and get in touch with us on Social @Adaptivist, on your favourite social media platform.

For Jobin Kuruvilla, Rasmus Praestholm, and Jon Mort, I'm Ryan Spilken – and we'll see you next time on DevOps Decrypted – part of the Adaptavist Live network of shows.

Why not leave us a review on your podcast platform of choice? Let us know how we're doing or highlight topics you would like us to discuss in our upcoming episodes.

We truly love to hear your feedback, and as a thank you, we will be giving out some free Adaptavist swag bags to say thank you for your ongoing support!