DevOps Decrypted: Ep. 12 - Musk's Twitter,  ChatGPT and other DevOps disruptions

Romy Greenfield:

Hello, everyone, and welcome to another episode of DevOps Decrypted. I'm your host, Romy Greenfield, and joining me today are Jobin, Rasmus, Jon and a new guest, Ben Davies, who is a Senior Software Engineer on the ScriptRunner for Jira Cloud team.

Hi, everybody!

Jobin Kuruvilla:

Hello! Hello! Happy New Year.

Romy Greenfield:

Happy New Year. It's good to be back.

Romy Greenfield:

So, today we're going to be discussing a bit of DevOps in the news. Twitter. Elon Musk.

What do you guys think about this? How is it still alive – what's going on?!

Rasmus Praestholm:

So I'm not going to come out as a Musk fanboy, or anything of the sort… and I think terrible things are happening. But I do think that he doesn't operate out of a vacuum. He sees their issues, and then he goes in and disrupts the heck out of things.

In Twitter's case, I'm not sure it's gonna lead anywhere. Positive. I could imagine that a year after, if Twitter is a tenth the size it was, some, like active users? Okay, that might be the thing.

But there probably were issues there, I mean, with Twitter not being profitable, and probably, you know, bloated in some ways… it's a hard balance between something, a tool that became such a global phenomenon of importance – like, politicians all over the world, using it as their primary sort of thing.

It's not a business. And I kind of lean towards the idea of having something there. But I can understand why somebody says, “this is not a terrible business. We're going to try to fix it”, and whether or not that works, ultimately… It's probably a good thing for the industry, because it gets disrupted to the point where all these new competitors start coming out of the woodwork and doing things differently and really, just hopefully lands in better shape than it was. But Twitter itself?

Uh…

Jobin Kuruvilla:

I think there is a lot to learn from this story, right? I mean, it depends on which sign you look at it from because from a pure business point of view, it's true that Musk paid a lot more than what Twitter is actually valued. I mean the fair value price was like 25 billion and he ended up paying 44 billion.

So from a pure business perspective, yeah, he needs to do something to save the money that he is invested in it. So he had to cut off a lot of fat, even though people don't like when we say it that way, but he had to do something from that perspective.

I think a lot of the problems arise from the fact, on how he did it actually, right? It’s not that he fired a lot of people. A lot of companies are doing that now, now that the recession’s upon us.

The fact that he did it in the worst possible way – that is why it is causing a lot of problems right now.

Jon Mort:

Yeah, I think it's the nature, the nature of Twitter as a platform, and the people that would want it, like it's always going to happen out in the open, and air the dirty laundry is going to be right there. So I don't know whether it was just a conscious decision to really front it up and do it all out in public, to look at preventing leaks and those kinds of things. I think, yes, it's fascinating how it's played out, and how he treated this investment.

Romy Greenfield:

I think… sometimes, any publicity is good publicity, right? So to me it's almost like he's just gone, “well, if i'm going to be doing lots of massive changes, and people aren't going to like it, but some people might… I might as well do it all out there, get loads of people interested.”

I was tempted to sign up to Twitter just to go and look at all of the chaos that was happening. So maybe that maybe that's worked.

Jobin Kuruvilla:

Wait, what you were not on Twitter before?!

Romy Greenfield:

Look, I’m an archaic dinosaur. I never really understood Twitter, so I just let other people go on Twitter and tell me what's happening on it!

Rasmus Praestholm:

I think one potential interesting part to this is, how is Twitter still online? Like from a technical or DevOps perspective, since you know, DevOps Decrypted and all that – how is it still running?

Jobin Kuruvilla:

Which kind of validated what Musk is doing? Right? What he's saying is, I don't need this many people to keep Twitter running and make it profitable. That is probably exactly the kind of message that he's sending out there.

Now, keep in mind that this has caused big damage to his reputation right? I think that was in New York Times… was all saying that Musk is not the genius that he was when he went and did Tesla, or SpaceX, so it is causing a lot of harm – not just his reputation. I mean the Tesla prices went way down to that.

I think he's not the wealthiest person anymore. So that's done a lot of damage in that sense, but he is, you know, doubling down and making sure that he is on the way to how he wants to run it.

Rasmus Praestholm:

And it is, you know – it's becoming, maybe not a cesspool. But all the moderation teams and things going away is bad for the platform. But again it comes back to the whole bit about why is, how is Twitter a business? What is its purpose? That's the sort of, the longer term output of what's going to happen here. But just from a purely technological perspective, it's probably easier to keep something online than it is to keep it pretty.

Jon Mort:

Yeah. Another angle a thing it might be interesting to look at is you know, what others do as a reaction. So I feel like there might be some cargo culting of Musk's management style, and things that people are doing without really understanding why. And one of the things that he's not really explained is the objectives of things. It's all been… what has actually happened, and what's been done without actually really looking at what was the underlying purpose and objective of things. So I wonder if there's going to be leadership who see what was done and see it as a prototype, without really without knowing why.

So, yeah, that's another thing that might be worth exploring.

Jobin Kuruvilla:

I think this is going to create a lot of case studies. Whether it becomes a success story or not, either way, there's going to be a lot of case studies coming out of this particular event saying, “okay Musk was right. That's the way to lead a company like Twitter”, or “Musk was not right. This is how you fail as a leader.”

Right?

Rasmus Praestholm:

And what's the difference between a profitable business and a reputable town square. They’re not necessarily the same thing.

Jobin Kuruvilla:

Exactly, and there was this interesting poll that Musk himself did about, whether should he continue CEO or not – on Twitter, unsurprisingly – but the majority of the people said no, and he's probably going resign also, if find finds a foolish person enough, in his own terms, to lead Twitter, so we'll see.

Romy Greenfield:

But… He didn't finish his poll, though, did he? He didn't do what he said he was going to do.

Jobin Kuruvilla:

Well, that was the caveat! I mean, as soon as he finds another person foolish enough to take on this role.

Romy Greenfield:

Yeah. But I could have put caveat into, like, the Brexit vote, and then just not done it! I think he should have stayed true to his poll.

Jobin Kuruvilla:

So – do we have any predictions for 2023, in terms of whether Musk will resign or not?

Romy Greenfield:

I want to predict that he's not going to. I think he's just going to keep holding on.

Rasmus Praestholm:

I think we should ask ChatGPT!

Jobin Kuruvilla:

We should probably do that…

Romy Greenfield:

That would be a great idea! Nicely onto another thing that's been very popular of late, ChatGPT: Have any of you been playing around with ChatGPT?

Jon Mort:

Yeah, I have when it's been available! And then this has been the problem of late with it. But it's a super powerful tool, and for me it's this combination of a lot of the technology, but also the user interface, and it's that combination. So GPT3 has been around for a little while, and it's been used in a bunch of things. And, frankly, ChatGPT isn't much of an advance on that.

But the ease of use of it and the interaction model – it significantly put it into people's hands. I think it's transformed the way people work and how they interact with things. So I personally use it in my daily workflow when it's available, to help draft email, or kind of work on ideas. You can kind of explore, explore things with it. And there's a lot of kind of noisy use cases like creative things. But actually, there's some really good boring use cases as well, just helping you work through ideas and things.

Rasmus Praestholm:

That's what I'm doing. I'm doing boring things with it. I'm making it write my Ansible scripts for me.

It’s pretty good at that, beats trying to search Google for like, just the right use case. It's much more of a smooth interface in that case, so I can see why somebody like Microsoft would wanna retrofit Bing to just work that way. So that'll be. That'll be interesting.

Jobin Kuruvilla:

And for the sake of our listeners I would say this – we have a Slack channel in our company specifically focusing on ChatGPT, and I would even argue that it is people like Jon and Rasmus, who have brought it down! You know so many, so many different code is sending to ChatGPT!

Jon Mort:

Well, I say it works fine in the morning, and thenNorth America wakes up, and then it disappears offline.

Jobin Kuruvilla:

Blame it all on us!

I would say I mean ChatGTP is definitely a revolution in the way people work. In my mind, at least, when it comes to artificial intelligence, it was all about face recognition. Until now I obviously, you know, companies like AWS has been investing a lot on AI recently and Microsoft, is another good example, but ChatGPT came as a surprise. It basically changed the way we work. Everybody has been Googling for a while, and, you know, relying on Stack Overflow for your code snippets. But, as Rasmus said now, it's much, much easier these days, you know you. You just ask the question to ChatGPT. There are so many, so many different examples; we were asking questions about RegEx, or how do we write Apache redirections. Whatever it is, for so many different use cases – even ask it to write blog posts for us.

Rasmus Praestholm:

Yep. Or making DevOps predictions.

Jobin Kuruvilla:

Or making devops predictions! That sounds a good example!

Jon Mort:

Well, I I kind of want to throw in a prediction about ChatGPT, and I think, and I suspect that ChatGPT… we will look back at it as a… as much of a significance as when Google came in and made search usable and work. I think it's kind of like an epoch moment in the way that humanity thinks about things and kind of up operates that.

That's my prediction. I might be over-egging it. But… I feel like it’s that significant.

Rasmus Praestholm:

Yep, I think that's right. It's an inflection point. It's been going from here for years, now, when somebody brings up AI in a business context, my eyes just roll over like, okay? Sure. Yeah, you're using AI for business, right…

Then ChatGPT, and like, oh, yeah, now we're there. And I'm still, not sure if any of those businesses using AI and machine learning as buzz words were really truly doing anything radical with it. But now we're there.

Jobin Kuruvilla:

Well, I mean just recently Microsoft actually released Bing which can then create images as we type in words and do it. So AI is definitely becoming popular. Believe it or not. I mean it is going to be used in businesses, and if for example, Romy we were talking earlier about creating a new banner for our DevOps Decrypted Podcast, I mean earlier you had to rely on our company partner to create that design. Now, all you have to probably do is, you know, Go to bing.com, and do a search, and you know, ask it to create a graphic for us. Right?

Things are becoming so much easier these days, and AI definitely plays a big part in that.

What is also interesting is, you know, ChatGPT, a lot of people are not going to like it. In New York, in public schools, they have actually said, you cannot use: it at school, because students were using it, you know, to write their assignments.

Romy Greenfield:

Which is a pretty good use case for it, because – my opinion – whenever you're developing, we always use little modules, and we use little libraries that people have created before to do the leg work for us, so that we can use that to then create something new and something bigger. So… Surely, actually, you should be allowed to use that to do your homework. So you can build on top of that.

Rasmus Praestholm:

I think a lot of the knee-jerk reaction banning is short sighted. We don’t know how to do this right now, so we’re gonna ban it. But long term, that is a much, much bigger impact, because it has been, you know, the way to bring up students is by having them go through these essays and research and things like that. Now you can ask an AI, which is great if you actually truly needed to make a research paper on something interesting, but a lot of it for students is just learning the process. When you suddenly have a tool that can just skip all that. How do you teach them to still know the process?

Romy Greenfield:

Hmm. Exactly. It's not going to replace software engineers just yet, but I have seen even some of the students that I teach have been using it to get some information that usually, they would ask a tutor, or they'd ask another student, and it's been really helpful for them. I have said with the caveat don't always trust what it says, but it's nice that they can use that.

Jobin Kuruvilla:

Absolutely. I think there was an interesting post in one of our random Slack channels which said, AI will not take a job. But people who know how to use it will definitely take your job.

Romy Greenfield:

Exactly. Watch out!

Rasmus Praestholm:

Yup. And as far as prediction goes. It is sort of an interesting angle on it, because if you ask it about, you know, making DevOps predictions for 2023, what you get back depends on what you put in in the first place. If you just want predictions, it will give you the boring, run of the mill, what everybody thinks on the Internet – which isn't very informative.

If you ask it to go outrageous in making predictions, you get some interesting stuff, but it's probably not super relevant to what's actually going to happen. Although I wish we'll get nanotech in 2023. But you know.

Jobin Kuruvilla:

And that was one of the outrageous predictions wasn't it?

Rasmus Praestholm:

Oh, yeah.

Jobin Kuruvilla: Cloud native technologies, and what else was there? I don't remember.

Rasmus Praestholm: So we had quantum computing, blockchain, virtual, augmented reality, neural networks…. self-healing systems, you know, language systems, nanotechnology. And then, for some reason, edge computing – that sounds kind of not outrageous.

So, it's a mixed bag.

Ooh, brain computer interfaces…

Romy Greenfield:

That'd be great.

Jobin Kuruvilla:

I would say, quite, quite outrageous. Given that, you know self healing systems. That's great to talk about. But we don't really have self-driving cars yet. Right? I mean, we have been predicting about that for years now. But it's not fully autonomous yet. So maybe self healing system is going to take a few more years.

Rasmus Praestholm:

Yeah, this is more like a decade or two for some of it at least.

Jobin Kuruvilla:

And that is an interesting aspect of ChatGPT. You can drive it into different directions. You can be good with it, and you know, get good answers out of it. But then you can be outrageous, and get really really outrageous answers from it.

I think it's all about how you treat AI.

Romy Greenfield:

I was going to say you should probably be nice to it if it's going to take over in the future.

Rasmus Praestholm:

Oh, yes, I use the word please a lot. And thank you, not because I have to. But you're trying to teach it to be a nice citizen, right?

Jobin Kuruvilla:

Should we talk about what us humans predicted about DevOps in 2023?

Romy Greenfield:

Definitely. I know that we've been looking at some predictions from a human level for 2023, and what the future has for DevOps. Jon, I know that you've been writing an article about that?

Jon Mort:

Yeah – well, one of the one of the things that people ask me to do in my position as CTO is, is that sort of attempt to predict the future and things, which is kind of… pretty much impossible to predict the future! But the approach that I tend to take with these things is looking at the trends, and where are things going?

So actually one of the things that I was that predicted, and we had published was here would be more of these browser development environments coming along – so there’s been some real work with, like Cloud9 and Git pods, and early this year GitLab announced that kind of browser development environment as well.

So that was one – having predicted that in November, I’m like, yeah, there's at least one that's useful in that direction!

The other trend that I see, is it's kind of shifting to serverless, and lots of organisations kind of skipping containers and going directly to serverless managed services and things. Building on those higher level abstractions that cloud providers give.

Strangely enough, that hooks up with the ChatGPT prediction about edge computing, but that's another one of the trends which we'd hook up together that actually, I think you can see developing over the next year or two.

So. Yeah, nothing outrageous on my part. But those are some of the things…

Jobin Kuruvilla:

I kind of get the feeling that you can predict the future!

Romy Greenfield:

You can guess. You might not be right…

Jon Mort:

Yeah, it'll be about looking at this, this time next year – you know, how many actually came true!

Rasmus Praestholm:

One thing I’ve wondered from time to time, is if service is going to become sort of the Achilles heel of something like Kubernetes, or if Kubernetes will itself be able to offer some serverless, like the GKE Autopilot, and so on, to stay ahead of the pack.

Jon Mort:

I think it will evolve into that direction… There is a really interesting discussion I was following on Twitter, Kelsey Hightower was talking about – focus on the business value that your code is going to provide. And so whether it's going to run in Lambda, or whether it's going to run in a container, or whatever, that's the packaging and the wrapping up of the thing. So if you focus on the intent of what your service is going to do, then where it runs makes less impact.

Rasmus Praestholm:

And I guess it's not like it isn't always Kubernetes behind the scenes, anyway, because you know something's got to host your serverless…

Jon Mort:

Yeah, yeah, I mean it's just who manages it. That's the question. There's always something there, and there are serverless projects running on Kubernetes, I'd love to see some of those come towards the functionality of Lambda, and Azure functions and things.

Jobin Kuruvilla:

Speaking about that, that is one of the predictions that we have in our blog is the increased reliability or investment in site reliability and engineering, and that probably is going to go hand in hand with this.

People are going to worry about the reliability numbers, and you know, how reliable the infrastructure is.

Jon Mort:

Yeah. And I think, with the move to serverless, it's the same kind of skills, but applied in a different area. And this is where organisations that are able to learn and have got good feedback loops, they're going to have the advantage over those who are kind of stuck in that.

Our teams run this platform, and this is the platform that they run, rather than – this is the customer that we serve, and we want to make sure that the experience for building for our customers are as good as possible.

Jobin Kuruvilla:

So, value stream management we kept talking about last year. And there are all indications that that's going to carry over to this year, and will become the next huge thing. I think there were a lot of reports about it, you know – in fact, our own Matt Sanders who was originally a host on the DevOps Decrypted Podcast – he actually wrote a blog about it, where he quoted some numbers;

“The Value Stream Management Consortium team has produced a 2022 report, and there was notable increase in terms of actually a four times increase in the number of correspondents implementing a value stream management platform”, which was very interesting, and so many other numbers that he has quoted in that article, that all point into the fact that value stream is going to be much much bigger in 2023.

Rasmus Praestholm:

I guess that I'm wondering what the value stream over at Twitter is right now…

Romy Greenfield:

Excellent – so, let's move on to something that we've released recently as a company at Adaptavist, and some inside info from the DevOps procedure on the ScriptRunner for Jira Cloud team.

So, a few of you might have noticed that we recently released Behaviours on ScriptRunner for Jira Cloud, and luckily we've got two of the engineers that were actually working on that release on the call with us.

So we've got Ben Davies, who's a Senior Software Engineer and Kristian Walker, who's a Software Engineer.

So welcome, both of you, thanks for joining us.

Ben Davies:

Hi: thanks for having us.

Kristian Walker:

Hi. Thanks for having us.

Romy Greenfield:

We'd like to ask you some questions. So…

How come it took so long to bring Behaviours onto ScriptRunner for Jira Cloud, and what kind of challenges were you faced with whilst implementing that?

Ben Davies:

So I think the reason that we didn't bring Behaviours straight over to Cloud was because we actually couldn't. One of the problems with Cloud applications is that Atlassian sandbox them, which means that for us to actually develop new features, Atlassian have to provide us with a set of APIs for us to build upon.

So, we basically had to just wait for Atlassian to realise how important Behaviours is for customers before we could start working on it.

I think one of the things that's come into play here is the migrations. So at the moment Atlassian are trying to get customers to migrate over from Service Cloud and I think one of the key migration blockers for a lot of customers is that they want Behaviours on Cloud.

So, fortunately for us, Atlassian have come along, and they've decided to work with us to provide this new API, called UI Modifications API, which allows us to provide the features that are available on Server for Behaviours.

Romy Greenfield:

Awesome. So, from a DevOps perspective, how did you address stitching together the two different technologies, that have bought Behaviours onto ScriptRunner for Jira Cloud, because I know that one is built on the Connect framework and Behaviours is actually built on Forge – which is the new framework that Atlassian have released for Jira. So yeah, what kind of things did you have to do, and what kind of difficulties did you have with that?

Ben Davies:

So, yeah. So you're absolutely right. One of the key issues was that Atlassian, whilst they provided this new API, is they only provided them us on the Forge platform, which is something that we've never worked with before.

And ScriptRunner is already implemented using the Connect framework. So we needed a way to stitch together these two different technologies. So, one of the major challenges throughout the course of it was trying to work out a way of, how do we get these two technologies to communicate, because I don't believe anyone had ever actually done this before.

So we started off taking this iterative approach which meant that during development we could regularly evaluate, and gain feedback really early on on the feature.

One of the other things we started to do was we implemented feature flagging, which meant that as the feature was being developed, we could get a good idea of customer feedback and things like that, and have it running on a production environment, so that we didn't end up with this problem at the end of the project where it was like, we were going to deploy, and then, all of a sudden, our feature only works on our development environment.

Another major issue that we've had with the product was towards the end of it, and that was to do with the observability. So when we're developing our connect framework application, we're regularly working with AWS, and AWS for us is providing a massive amount of features.

So we'll work primarily with Lambda functions, but with those they come with a metric, and we can then easily apply monitoring, so we can get alerting on when something is going wrong with our application, and what specific part of the system is failing.

One of the problems that we have with Forge, which is the new platform as a service that Atlassian provided – whilst it will notify you that there are certain errors with something it won't actually tell you the specific part of the application, which for us is really crucial when building a production application.

It was really frustrating towards the end of the project, where it was like, we built this thing, it was ready to go out, but then we realised we couldn't actually monitor it successfully.

So, because we've been working closely with Atlassian, we managed to provide feedback to them about that platform, and I think they've taken our feedback to heart. They are working on these changes which should improve development for people who work with Forge in the future.

But one thing which was really frustrating during that time was that we had to build our own in-house Forge metrics service, which would then provide us that key information so we could actually release this to customers and get an idea of whether or not it was running correctly or not.

Romy Greenfield:

Oh, yeah, there was a lot that went into this. I know that as well, I feel like we had a few kind of deadlines in our heads about when this was going to be released. Can you tell me a bit about how the team dealt with the ever changing deadlines, and on the actual release date – did anything go wrong?

Kristian Walker:

Luckily, we had a very good project manager in Jill, who kept everything well documented, and we just kept building as much as we could until, when we promised we were going to build it.

But we were sort of met by challenges, from Atlassian where they were promising us bits would be built already by a certain date, and then they would push them back, which obviously meant we had to communicate that to our customers – which is hard.

And in terms of release – the first time we tried to release, it failed. Yes, so we released, we turned it on live and we found it wasn't working as expected in production. So we then had to then roll back and then go come back the next day, and rerelease, which was challenging.

Romy Greenfield:

Yeah, not exactly what you want when you’re releasing something!

Jobin Kuruvilla:

So, for the people who are not so familiar withForge or the Connect platform, what are some of the technologies that Behaviours and ScriptRunner runs on? Is it all in AWS? Is it on Kubernetes? What exactly is the technology that powers it?

Ben Davies:

So ScriptRunner as a whole is built using the Connect framework, and that's all completely built on AWS, pretty much. So we've got services that run on Fargate tasks, but then we also use serverless in some cases where we're heavily using AWS Lambda functions.

What Forge is, Forge is just a new platform as a service Atlassian have provided that is built, I believe, on the back of AWS. So with Forge, you get things such as Functions as a Service.

Also your frontend, or, like your UI code can also be hosted on Atlassian’s end, whereas at the moment what we're doing with Connect is we're hosting things – we're basically storing things in an S3 bucket, and then we've then got CloudFront that provides some form of caching.

So, Atlassian are trying to basically make it so that when Cloud developers build products, they don't have to use their own platform. They have to then use Atlassian’s platform.

Another benefit, apparently of Forge, is that it provides authentication with Jira Cloud automatically. So, it's meant to make things easier, but we found, while some parts might be easier in the future, at this moment in time, we found the platform was a little bit too early when it came to features. It wasn't particularly feature rich, so we really struggled that early on, when we're so used to a feature rich product like AWS.

Kristian Walker:

Yeah, I think, on top of what Ben said, the big challenge we found is, we didn't know exactly what the runtime was under the hood that Atlassian we were running the code on. So we were developing our JavaScript into pipes and just assuming it was running on Node.

But we then later found that Atlassian have some bespoke environment that it’s running on, which led to some challenges because some packages wouldn't work or some things wouldn’t work as expected – because the modules didn't exist that we thought existed. So we had to develop some workarounds to work on that. And that's a piece we've fed back to Atlassian and I believe they're going to change that to make it easier for developers in future.

But that tripped us up a few times, and took a while to work out.

Jobin Kuruvilla:

You know, one of the DevOps predictions that we had for the year was minimum viable architecture. It does feel like Atlassian is implementing that into practice by, you know, releasing Forge early or with the minimum viable architecture, so people can give feedback on it, which Adaptavist apparently is giving a lot of!

Ben Davies:

Oh, so I was gonna say, we've been in very close collaboration with Atlassian, which has been one great thing about this project.

We've had a Slack channel open, and the people who we have been working with at Atlassian have been really helpful. Like, we post questions, and they immediately answer, and they've been really informative, and have taken the feedback. So it's been great from that side of things, from the collaboration side.

But yeah, there have been a lot of challenges.

Kristian Walker:

Yeah, I have to say, we’ve hit some bugs where Atlassian have released a new version, and we’ve upgraded to it, and then it hasn't worked so we've raised it in the Issue Adjustments Channel, and they've jumped straight on it, and they fixed it the same day or the next day. So the collaboration has been really fast. From that point of view. It's been really good that we work so closely with it.

That's great!

Jobin Kuruvilla:

So, what is the feedback from some of our early adopters, from our customers? Are they loving it? Hating it?

Kristian Walker:

I think at the moment, customers are getting used to it. But at the moment, the main feedback is it doesn't satisfy all the requirements because it doesn't match the same as Server – because we currently don't support custom fields. But we're working on that right now, and hopefully, we should be able to release that very soon.

Another piece of feedback which we see is that it doesn't support all the Issue screens but currently, due to the difference in the architecture between Cloud and Server, we're tied on that – because, like Ben said, we build on the UI Modifications API which Atlassian provide, and that only runs on the global Create screen, but that's not something we can configure our end, that's something we just have to wait for Atlassian to support other screens.

Once they support them, our app will work on their screens, but we're tied in not being able to do that from Atlassian's end, which is a big difference in developing for Cloud to developing for on-premises.

Romy Greenfield:

Yeah, and I guess there's a minimum viable architecture that we've built for Behaviours. Going back to what you're saying Jobin, we're kind of incrementing. We're increasing the amount of features that are going to be available with Behaviours.

Jobin Kuruvilla:

And it's good to know that a lot of this feedback is about the feature parity rather than anything else because, given what you are saying about the different platforms and how we stitch it together, a concern of mine would have been about the operational aspects of things right, I mean how reliable the application is, especially given how this stitching is done together.

From what I'm hearing, I mean, there have been no complaints on that side of things.

Ben Davies:

Yeah, I think I think people are just really happy that it's coming to Cloud… The stitching bit wasn't ideal, and I'm sure it's like, not the best experience for customers when they're installing. In an ideal world, we would have built the thing on Connect, and then it would have just been a seamless admin page that the customers would have just seen, they would have clicked on it, and then there would be no extra installation process.

But it seems like, because Behaviours is so important to them, that's like a small detail now for them. And now, it's just like – they want custom fields or customers are saying, they want new fields to work with, or as Kristian was saying they want on different screens, and things like that.

We're working on introducing custom fields, which is something that we're hoping should be out soon.So, the feature parity is slowly, you know, increasing.

Jon Mort:

Ben, you mentioned that adding the observability and metrics for this was kind of a frustrating last minute experience – looking back on that, was that worth doing, or would actually releasing and flying blind with that – would that have actually been acceptable for you? Given the value that customers are getting from it?

Ben Davies:

I think, looking back on it, whilst it was a challenge that we weren't really expecting it was, I think, it was worthwhile. It's really useful now… So, the way that we've hooked up the system is that we've got these AWS Cloud watch metrics, and we've got alarms configured to those. So I think it's really nice that we've released it, and we can log off and think, “okay, well if something does go wrong, we're going to get notified of it”.

I think it was worthwhile, because at the moment, especially when we're in incidents and things, we can use those metrics to then be like, okay, which part of the system is actually at fault – whereas, if we do if we just use what Forge was providing at the time, it's like, we just got an email where it's like, “something is wrong”.

It's not as helpful, and it doesn't help us resolve the issues as fast.

Jon Mort:

It's been a long journey, you know – pretty much from the inception of the Cloud version of ScriptRunner, customers have been asking for, so it's brilliant to be able to actually deliver that and meet that need.

Jobin Kuruvilla:

I'm still going to complain about the missing features – but at least it's up and running; it's not like ChatGPT! I cannot rely on ChatGPT now…

Romy Greenfield:

Well, Thank you both for joining us, Ben and Kristian. It's been really informative having you on the show.

Ben Davies:

That’s great; thanks for having us.

Kristian Walker:

Thanks for having us.

Romy Greenfield:

Thanks for joining us today on another episode of DevOps Decrypted. We hope you've been enjoying the show. Please let us know what you think on social media @Adaptivist.

We look forward to keeping the conversation going with you guys there!

I'm Romy, and this has been DevOps Decrypted, which is part of the Adaptavist Live Podcast Network.

Thanks for listening!