DevOps Decrypted: Ep. 21 - Platform Engineering: The performance stage

Welcome back to another episode of DevOps Decrypted, where we unpack the events of KubeCon and BackstageCon. Host Laura and our resident DevOps Decrypted gang (Jobin, Rasmus and Jon) are joined by Mike Maheu – GM and Co-Founder of Venue.sh, part of the Adaptavist Group.

And this episode arrives just in time to prove some of our predictions… Last year, we highlighted platform engineering as one of our picks for “the next big thing”, and it looks like we're about to see it come of age. Mike and the team talk about Venue.sh, the difference between DevOps and platform engineering, and how together they can enhance experiences for everyone.

Welcome to the DevOps Decrypted podcast, the show where DevOps is what we're here for.

I'm your host, Laura. And with us today, we have a guest speaker – Mike Maheu, from Venue.sh!

It's part of the Adaptavist group, and we're gonna talk to him a little bit later. But first, we're gonna talk about some DevOps in the news…

So, who wants to bring us in with BackstageCon?

Oh, that sounds like a wind-up for me then, since I'm the Backstage nut!

Yeah, there was a BackstageCon. It's one of the co-located events at KubeCon, which was like last week. And after some initial like, wait, what this thing is live, streamed? Wait! Why did I get a virtual pass? Then, I finally caught up on some of the recordings, and there are a lot of neat, interesting bits and pieces in there, including, of course, somebody through generative AI prompting on a page in Backstage. So now you can, you know…. Just live in there. Just live in there…. It's all good.

And there are a bunch of other cool sessions in there. I know. Their Plugin manager is coming soon. They're talking about marketplace things. The Beta sign-ups for the quick start are coming out – loads of stuff, and that's just one co-located event; there is so much stuff happening at KubeCon…. so did any of you catch any cool sessions?

Let me clarify, Rasmus – was this actually part of KubeCon, or was this completely separate from KubeCon?

It's part of it. They actually do a day zero series of co-located events at the venue, which is like Backstage and other things, kind of like sub-events. But they do happen at the same event.

That is awesome. Yeah, I mean, based on whatever I have seen, I think ever since the last AW3 event, there is this focus on Backstage. And obviously, within our company, we do focus on it quite a lot.

But even outside of it, I have seen a lot of focus. There was a lot of chat about it last year at the AWS event – I expect that probably this year as well.

But it is fascinating to see a complete event, a new event, coming out of it. BackstageCon. Very interesting.

It might have been the second year they did it. It's still fairly new.

Did we learn anything new from that, I know. We are actually using Backstage internally for quite a bit of things.

Sure. One cool thing is that we are now officially partners with Spotify Backstage. That was not really a thing at the event. But I know this, and I'm excited because that means more cool things are coming. So we really need to digest, you know, all the things there and start doing well with them.

That is awesome. Speaking of events, I was at one of the events last year as well. Sorry, last week!

I'm just saying… This year, it's flying by.

But yeah, last week we had Agile DevOps East in Florida Orlando.

Actually, Mike also was there with us, but I'm going to leave it to him to speak about that.

The Agile DevOps East that was a quality event as well – a lot of discussions about DevOps in general, Backstage did come up quite a bit. We did talk about platforms. Mike and I did a presentation about the common digital pitfalls that we see in our engagements with customers and why platform engineering could help us with some of those things.

Again, similar to Backstage. We have been hearing quite a lot about platform engineering in the last one or two years. That's probably a good place to start this podcast: what do you think?

Yeah, let's get into platform engineering because I think that it's a really interesting part of, like, yeah, where DevOps is evolving to and moving. So, yeah. Let's get into it!

I remember Platform engineering was definitely one of the predictions in almost all of the predictions that came out last year. We did one, Adaptavist did one, too, and that was definitely one of the things in there.

Platform engineering is going to be the next huge thing. In fact, that is one thing I was talking about in the talk. Also, by 2026, 80% of the software engineering organised sessions will establish platform teams as internal providers for reusable services, components, tools…

That is a huge number. 80% by 2026!

I don't know how many companies have actually started on platform engineering.

In fact, you know, many people who are probably hearing this podcast will be wondering what exactly platform engineering is.

Jon, do you want to maybe talk about that a bit?

Oh, yeah, I go for the high level of the sale, and then maybe people can chip in with, "so what does so what does that actually mean?"

So I see platform engineering as a way of enabling teams to ship more consistently and make visible the services and tools that are available to them.

So this is about is, it's about accelerating teams to ship better quality software with the right guardrails.

And yeah, how did that do? What did I miss out on the platform engineering definition?

No, I mean, I will. I'll throw in a thought.

Also, I have thought about platform engineering a lot in that. It's already becoming vague, like DevOps, like it can mean anything you want to. And it's like, what would be a really good way of positioning the two together to contrast, what does DevOps mean? And what does platform engineering mean?

And I came up with one where I think of DevOps as when the Dev and Ops monoliths were kind of like smooshed together in that you came up with this idea of like interfaces rather than throwing things on the wall, so that, you know, operations come up with a process by which developers can interact with automation that gets their stuff happening sooner.

And it was also a big cultural shift in that you had to get out of that mindset of throwing things over the wall, and has left operations as some group somewhere else over there.

One thing I'm thinking with platform engineering is that it went from being those two monoliths, kind of smushed together like a strip of puzzle pieces – as they connect together now – but there are still two things that are connecting together.

Whereas platform engineering, to me, feels almost like you're breaking apart the entire puzzle. And all the teams have their individual little puzzle edges, with interfaces with how they interact with other things. And you absolutely need some internal platform to make sense of that because services without organisations? It's gonna be a disaster unless you can keep track of it.

Yeah, I think that's a really great way of thinking about it. One of the anti-patterns that we see with DevOps teams is when you expect teams to go, right, you're now a DevOps team. You now need to care about the entire stack. And the cognitive overhead of that for the team, for, like, you've engineers who have never done any infrastructure.

You go. And right here you go. You've you've you've not gonna manage everything like run it. You build it, you run it and other things…

You can really slow a team down while going. You've got all of this stuff to manage now because there's a whole load of uncertainty, added you kind of erode psychological safety in the team. So they're not happy to take risks, and you end up just grinding to a halt.

And I see kind of platform engineering taking that problem like chipping away at it a little bit, and providing those the ways to build, and that sort of safety to remove some of that cognitive overhead, and give you a platform to build on. I've overlayed the term, but it gives you that contextual safety to build and build fast and to iterate in a way that ultimately gives better value to customers faster.

And that's really the goal for the whole thing.

So, put it in simple words… I mean, if I am an application developer, I can now focus on the application development. I don't have to worry about where I'm going to deploy. I mean, I don't have to worry about the Kubernetes infrastructure that I need to build. I don't have to worry about the pipelines actually to build and deploy it into the Kubernetes environment.

It is all taken care of by the platforms. Is that what you are saying?

Yeah, there's a kind of a contract between you as an application developer, and as long as you make that contract, the platform will meet its contract, hopefully. And you've got a stable place to be building on, where you know the lines of responsibility.

So, you're still responsible for deploying, managing, and running your application.

But you don't need to deal with all of the details all the way right down to the bottom. You have a layer to hide that from you.

So, I already have the right tools on the infrastructure needed to deploy my product successfully. Okay, got it!

One way I think about it actually is that the Dev and the Ops were throwing it over the wall. So you got dev off on one side of things and switched it 90 degrees.

The application is being delivered by the application team throughout, end to end, so they're responsible for getting the application code into the customer's hands. But the platform team, the platform engineering, is responsible for delivering the platform that enables that to happen. So you've knocked your wall over, and you've, and you've flattened it out a little bit.

That makes sense.

I'll also throw in a callback to a previous episode when we talked about Kubernetes and how – can you really get away from the complexity in Kubernetes and development overall – and sort of the answer that is… not really. But you can move it around.

When we think about platform engineering. I'm thinking, while we are going from that world where it was just developer and operations, there was a huge interface between the 2 of them and all the different things you had to worry about.

We break down into small puzzle pieces.

But we haven't really reduced complexity; we've just put smaller chunks of complexity on different individual teams.

So even though when you need some code deployed, you can easily find – oh, yeah, OK, that's the team, that's the home there, that there's their policies to this fall as far as OK. That's easy.

But then you are also responsible for developing a contract for what you do.

So, if you at all are depended on by anybody else, you also still need to take ownership of that bit of complexity and make it clean so that all can interact with you really well.

But maybe there are different ways of abstracting those complexities, and I'm sure Mike will probably tell us more about that later on.

But before we do that, I was at the DevOps Days in Washington, DC. Probably a month back? Or maybe even two months… as you know, I'm losing track of time – but again. In that one, there was a concept called open spaces, where we actually formed small groups and talked about the things that interest us the most.

And I was in one of the open space talks about platform engineering.

One key thing that I noticed was many people in that group thought platform engineering meant IDPs – internal developer portals.

They actually confuse platform engineering with IDP. Now, IDPs are a crucial part of platform engineering. Right? They do abstract away a lot of the complexities that come with the different tools that add to the platform. But it doesn't do CICD by itself, or it doesn't do Deployment. It doesn't do Git ops.

So, how do IDPs differ from platform? And why is it important? We did talk about Backstage, which is one of the most powerful IDPs out there today – but how does it actually fit into platform engineering? How? How is it different?

Does anyone want to talk about that? I mean, I can give my version.

Obviously, you know, I would say that IDPs are definitely one of the primary components. I mean, it is sitting in the front. It's sort of the way up slacks, and it becomes a self-service portal that will let you use the underneath platform. It is part of the platform. But you still need something to do CICD and infrastructure behind the scenes. As a team that's coming on board, I start by, you know, probably creating repositories for myself. Projects for myself, an environment. Maybe the dev environment, staging environment, production environment, all of that needs to be done.

But I can now do that with the help of my internal developer portal; there are templates that will help you do that, which will then help me get up and running really fast. But it is still connected to all those tools behind the scenes in the platform.

When you say the platform assets, IDP becomes a core part of it, but that is not the platform. There are other tools that are in the midst, which will then enable you to do that. Does that make sense?

Yeah, it definitely is. And I am definitely guilty of thinking that Backstage is like the platform for all the engineering. But it's really more like Backstage or the IDPs front all that stuff, which includes your CICD, your Jenkins, your SonarQube, all the things; they can look at all of it.

So, in a sense, it is the pane of glass, as it's so often referred to, to your overall development estate, which includes all the platform engineering bits that you deal with.

But of course, you don't get that for free. That's why it's both a cultural journey and it's a huge journey of just getting all your tools and processes put in there – and all your people.

Let's not forget. You know, people process as part of the DevOps triad, it so often gets, you know, left behind.

So you need all 3 of them to make it work, and that's difficult. And that's why we did something we could talk about here, which is why we have Mike here, who is still not my boss… I don't know him at all. I don't work with him.

But maybe we can see what he's been up to?

Yeah, I think so. I will make one quick point... It is all about the developer experience. Right? I mean, that is what Backstage provides, and in some cases, that is what? You are probably on top of what Backstage already offers.

And with that said, hey, Mike, how are you?

Hey. Boy, it was hard not to talk that whole time. I'll be honest.

Yeah, I'm sure you have much to discuss platform engineering!

And specifically Venue – so tell us, Mike. What exactly is Venue? How is it maybe different from Backstage, or how does it fit into the platform engineering model?

Sure. Well, we certainly all of you touched on different aspects of it. But you know, first, I will say that Backstage out-of-the-box is quite simple. Or I should say, there's not much to it; it really, 's it and that's for a good reason. It allows companies and teams to make it their own, and an IDP should be customised to the teams that use it.

It's not one size fits all. And I think that's where the complexity comes in because there's a lot of initial configuration. Nothing is automatic out-of-the-box . So there's quite a bit of effort to get Backstage kind of customised.

It's more like a framework.

Yeah. So what is part of the reason for us doing Venue.sh – and we are launching in January – is to take a couple of the things that you've discussed and offer them in a platform, that is, you know, the IDP itself, with some pre-configurations and kind of kicking it into the next level, with some customisations and plugins.

But, more importantly, having the flexibility of an entire platform. So the Venue.sh side is that curated catalogue, where companies can decide what tools they want to provide to their teams, and they can be in this catalogue. And then, once a company creates their own Venue, which is again a place for the Dev teams to do their work, which includes the IDP, it is Backstage.

They can create one or many stages for each team. A stage is basically a set of tools and configurations. Compared to other competitors, one of the big differences with Venue is that we have automation in place, and we use GitOps to deploy these tools into a cloud-native environment.

So these tools get deployed into a container, into a cluster with all the other tooling for the stages across the teams. It also does automatic updating. So it's not where you have to deploy your tool manually, then go into Backstage, do a bunch of YAML to connect it to Backstage…

It all happens just by creating the stage within Venue.sh.

It deploys the tools into the Kubernetes cluster and links it to Backstage. And so you're off to the races. That's a huge amount of complexity that's just been removed. And even if you use AI or ChatGPT and you search, what do you need to do to get the next JS app and to be able to deploy to a cloud-native environment?

And you'll get a list of about 30 things – not many of which are very easy. They're all fairly complicated, you know, with ingress in the cluster and networking and security – and so we wanted to take a lot of that complexity out to help companies basically be cloud-native, deploy value to their customers faster, in the best practices way in providing the visibility across the platform and the deployments and the rollbacks, and all the and all the activities that happen when teams are deploying applications.

Alright. So that's a lot to unpack there… So I'm going to. I'm going to start with some basic questions. So I understand when you said product, so is it like a SaaS platform that people can sign on to? And you know that will actually help them up and running fast in their DevOps standing.

Yup. So, it's a platform where you can sign up and add one to many users. One of the nice things about Venue is its onboarding feature, which I think is lacking in other platforms.

You can onboard as individuals at sign-up, and then you can actually join teams. In the future, we'll have more dynamic things around teams and how teams work, what the makeup of a team is, what type of development they're doing, and some data around that.

But yeah, you basically go, and you log into the portal. And then you're looking at your portal, which is the Venue.sh portal. Within that portal, you can again create stages, configure your teams, and look at reports and analytics of things that are happening. And then also go over into your Backstage environments where the teams do the work and do CICD. With whatever GitLab or whatever tools they have.

So the tools that you mentioned, like GitLab or Github, or whatever you mentioned that they are going to be part of. Are they going to be installed as part of the stages that we create in Venue? Do they get installed on SaaS as well? Or can I have the CICD tools running on-prem or behind in my AWS environment? Is that possible?

Yeah. So we provide both things you can connect to an existing one, or you can spin up a new one, so you have the option to do both. There could be more than one git provider as well. If you have more than one.

Okay, so the teams get the control run. What tools do they want to use, and where do they want to host it? But Venue will help them get them up and running…

It helps them get up and running. It also helps them with versioning of tools. And then, of course, if everybody's configuring and choosing tools, if you've seen the chart of the 1,000 tools that are available, teams will typically they may have used some of the same tools, but they may be using different versions, and they may choose tools that maybe, you know, are not really compliant to, or they're kind of outside of the the box of what the other teams are using.

So yeah, I mean, Venue just helps the organisation align, like I said, a curated catalogue. You want the developers to be able to choose the tools that make them work the best and deploy the best software. But it is nice to have some controls or some guardrails, as Jon put it, to make sure that the teams are choosing tools from a curated catalogue, and that they're being updated, and to the latest versions and things like that when they choose to.

So that not only gives a good starting point but it will also help enterprises put some kind of governance over what gets us on, and you know how they are using those tools.

Right? And they have visibility. So you can see somebody, whether they're at the Dev level or above, they'll be able to go and look at all the stages. They'll be able to see the tools and the versions of tools that are being used for that team to deploy their application.

So it's a one-stop view. It's kind of a view of the landscape. A lot of that stuff is just simply not visible, you know… different folks from across the company may never log into GitLab, or they may never log into Backstage.

We try to have Venue.sh be that one place where anybody in the organisation can log in and get some value out of it. Not just devs and dev teams.

Sounds good. I know that you are actually using Backstage as part of the tooling that you provide. Is that going to be the norm going forward, or I mean, are you thinking, I mean, if there is another IDP that I want to use?

Or if it is something that we have custom-developed within our organisation. Will we be able to use it? You know, at some point?

Yeah, right now, we're pretty focused on Backstage. It is obviously popular, and it's open source. Earlier in the year, I did a talk at Atlassian Unleashed in Berlin, and that talk was about using Compass as the IDP. So we do have other interests.

And we are thinking of building in functionality to be able to choose the IDP. But as of right now, there aren't that many, and obviously, the one that's in the limelight and has been for a little bit has been Backstage.

Quick question… Again. Once all those tools get deployed, you know… It's a platform at the end of the day, and you need to have the tools integrated with each other; for example – I might actually need Jira for project management, right? And I need GitLab for CICD, for example, and I'm deploying it into AWS, into Kubernetes clusters, maybe EKS. So, do you also help them integrate these tools together? How does it work, or do I have to ask the customer, go on, and then integrate all these tools myself, which is again a pain?

Yes, yeah. So that's definitely part of the foundation of the product and the platform.

Obviously, the first thing that they integrate is with whatever git management software they're using, whether it's GitLab, GitHub or Bitbucket.

But in the back end that we've built, there is a menu called integrations. That is where they will be able to integrate existing software. In addition to that, we're building out our own REST API as well, so there'll be back calls into the Venue.sh, platform.

I know Rasmus is on the call and part of the Venue team. So I'm going to actually call out on him because it's not always about the tools, right? I mean, you did touch on this a bit earlier.

You were talking about the people and the processes. How does it actually work when you help with that part of the equation?

Sure. And I'll preface that a little bit. With that. There are so many tools, frameworks, templates, and cool things out there, and it's like you have this gigantic box of just pieces.

And the trouble with something like Backstage right now is that it's a framework for this. So you get this box of really cool things, and like, “Good luck!”, whereas I said, you both need to figure out how to put that together. Well, and then you need to get your people into it, which is really kind of the big one.

So when I looked at, you know, when we started working on Venue in the beginning, and we talked about these concepts for years because Adaptavist as a whole… have been doing all these things, and like – what is missing?

And it's really the… It's really the coordination and the integration of those things with people that's missing.

So I looked at something like Backstage and looked at the Spotify Premium plugin package, and they helped some.

You know, they have some stuff more than what's available open source and then, but there's still some things missing.

And the thing that was missing largely was when, as a developer, you log in or start in the day, like – okay, where do I go?

And you know some companies and vendors, and they have thoughts on it like, Atlassian would want you to go to Compass, or something like them to start looking at things. And I was thinking, okay.

I would want you to go look at something like Backstage or Venue. But then, what concepts do you look at inside them? And to me, that's the connections between things. So I came up with this small series of additional like editors or hubs for things that you can then start with if you're curious about a particular area – which is like for the Venue side of things, that deploys tools and provision stuff for you, is largely about stages, which flits together;

What are you working on? Where are you working on it? Which tools are used to augment it? And so on. So there's the stage designer that gets into figuring out, okay, how does my stage for my work look like? And then, after you've made it, it's not just left there alone.

That's what happened since I'm like Backstage a lot, where you make a thing. No, there it is; good luck.

Whereas the stage designer gives you a stage where you can start even for like weeks and months after you begin to look at, well, yeah, we've been working on this thing. Now we have eight microservices and two databases and form environments and all this.

We need to add this new sub-feature that's gonna add, like, three more microservices in our database. And all these things. Okay, I drag and drop and add them over here and over here and then, oh, okay, they all just slip into place. And now they are hooked up to all the other stuff.

And on this page, I really have that view of what is all the stuff involved with this. With these things. And then you go beyond that and do a similar concept for other things, like individual teams.

What happens more frequently now is that you're not just your Org chart.

If you're a really, you know, nimble organisation, you might temporarily make, you know, virtual teams that work on some hot topic issues for just like a sprint or two, even though you might report to different people.

So that's the thing in there that you start that process like we have, you know, we need a tiger team, or whatever it's called that these days.

We need 2 node developers, an infrastructure person and a security guy…

And you just like, Oh, okay. So I can filter by people and just like, see who's available and who has the skills, and then put them in a team, and then associate that with a stage – and like, Oh, okay.

That's pretty cool.

And then it kinda just goes on with a continuous, you know, look at what happens over time. It's not just at one point in time. Yep, I provision it too; old good luck or I made a microservice. Good luck! It's like all those things – for the entire life cycle.

You have to look into what's going on. You can go change it. You can go update it – even to where, say, you started on a mobile application. And you know you were working on… Zune, or whatever one of those things that died really terribly.

The concept must still be solid. That's the same kind of idea, the same kind of application.

But you have to retool your thing completely. It's still the same thing. Now, you've just moved some of the pieces around.

But you still have that look of where has this thing been over the years with all the analytics you want?

So that's the long and short of, you know, some of the things I am excited about.

Yeah, Creative Hubs is part of Venue; we call it that, and I thought we were talking about DX, but I thought it's also about TX – team experience for us and the alignment with teams in the tooling stage. Because, again, these things are complex.

And you know, Jon, I think at the beginning was talking about, you have developers with skill sets, and then you have DevOps people with skill sets, and those two things don't always work well together, those two groups. And so maybe some of the stuff that the DevOps group is dictating to the teams doesn't make them as agile and, you know, have the ability to deliver value fast – because it seems like today, with companies moving to the cloud… And you know, whether they're in a digital transformation or they're towards the end of it, that they, you know, they can get features, and they can get things to work on, and they can sprint, but where they struggle to go at the same speed as deploying to production.

Thus, one of the main focuses of Venue is to help companies become cloud-native to where they can deploy to production.

You know, within, you know, in minutes instead of weeks or months.

That brings up an interesting question for me, at least. So, who are your target customers?

Because when you look at it? There are at least in my mind there are three types of customers.

One is startups – the green field, which is very easy to deal with. Right?

You already have a set of processes that you probably want to put them on. You know you have the templates in place. Best practices templates – very easy to get them started. But then there are enterprises or companies who are either starting their digital transformation journey like you mentioned, or people who already started the journey, but they are at a stage where they are taking a pause on rethinking, or we are not on the right track.

We call it data DevOps on the services side. Right? They need to rethink their strategy. So, who exactly are your target customers, or do you have one?

I like to think that – and my background and I think our background is more on the Enterprise side, even going back to when I was a developer, I developed enterprise applications. So, things that needed to scale and that had a lot of people and a lot of lines of code.

Startups, obviously, are more nimble. They have, you know, more flexibility. They can be more cutting-edge.

So I see that those would be good customers for Venue because they can sign up. And they know what they want. And they can choose those things and be off to the races without building it.

But I think a huge amount of value with Venue is again with enterprise customers and being able to do team onboarding, and have that curated catalogue and have some guardrails around what these stages have and what the tooling and what the environments are – and again, to deploy to cloud-native environments instead of to a virtual machine or virtual server, or whatever they're deploying to currently it just speeds up that whole process.

And you know, if you look at the Netflix story… Millions of dollars, years of development. And you know, they're still working on it, I'm sure! It's a great, a great experience for their developers, I'm sure. But that takes, you know, we're trying to provide that experience out-of-the-box basically.

But at the same time, let the customer, let the customer's organisation make it their own. So again, providing them with that backstage experience that's customised for them, and then that curated catalogue that they can, that they can build themselves, and then hopefully towards the middle and latter part of next year, we'll have more of the creative of part built out, and a lot more of the reporting and the analytics. And hopefully, some AI features.

Yep, and I think that's a great segue into one thing I want to bring out there, which is a little crazy. I know – that's me, I went through something crazy...

But I also want to grab a very obvious challenge we're gonna face, which is that enterprise customers have a lot of stuff already.

So, like, how do you take a platform that serves all these beautiful green field potentials and wrap that around something that exists already?

And we've toyed with the idea of this on-stage concept of how do we get that existing stuff onto a stage? And we have some thoughts on, you know. Well, I mean, we'll have some templates you kind of like, rebase your stuff on top of.

And then you get the benefits of that being a curated template. So you get the updates and all kinds of cool things like that…

But what we really want, or what I would want, because I'm a nerd, is to get that level of… it's almost an analogue to how now you can make customised GPTs, Where you can take something of ChatGPT and feed it a bunch of contexts, and he says, okay, this is us now, this is us.

But that with your entire like platform and identities of business, fit into a platform with some level of AI and all that, so that, you know – well, when we make a brand new thing we haven't done before, we're getting into a whole new language or a whole new, you know, project area… Start this thing with all the things we normally do, which there needs to be some awareness of; how do you normally opinionate your template and your tools?

How do you interact with audibility and all those kinds of things?

Okay. Apply all that to this new thing over here. And magic. Somehow, it happens.

Now, whether we can pull that off will be another question. But considering how AI is developing right now, I think if you can get to the point where you're making your custom GPT, but as your entire company platform engineering thing, I mean, that would be amazing.

That sounds like definitely the way to go in future. But let me make sure… I mean, that is, Venue.sh 2 dot 0 that we are discussing???

Might be. Might be…

1.5

Yeah, it's crazy. It's going fast.

Alright – anything else you want to add about Venue or platform engineering in general?

I know you talked about developer experience as well as a team experience, which was very interesting because a lot of the time, we are focused on developer experience. And I think Rasmus was speaking about how we can onboard people and processes on to, you know, these IDPs, all the platforms, I guess, speaking about anything that we are missing here?

Well, I wanted to ask a question. Actually.

So I think we've focused on some of the like, what's the experience as a developer?

But I'm interested in what the experience is like and what Venue brings for leadership – so for engineering, managers, directors of engineering, or CCOs or CIOs. What is the story and the advantage there of bringing some of these things together?

Yeah. Well, first off, the Venue.sh dashboard itself, I think, is gonna be huge because it's not just geared towards, you know, it's looking across the landscape. So again, they'll be able to look at all the stages and see the different tools the teams use.

But also, we will have reporting, whether it's DORA metrics or other things. So somebody could log into Venue.sh and see that, oh, the mobile team had a rollback, and did our feature get redeployed? And how fast did that happen? And does the customer have that value?

So, building on that, and also the concept of dashboards per user – the type of user logged into Venue.sh will be able to have their own kind of dashboard that shows things that they're interested in.

And then again. One of the issues that we saw with one of our longtime customers is they had more than a hundred Dev teams. A lot of them use Jenkins and similar tools, but each team has different versions of the tool – so again, the CTO would be able to say, Oh, let me look at our curated catalogue. Okay, I agree with that catalogue. Those are the tools that we want our teams to use, and we want everybody to be on this version. They can set that in Venue, which will automatically update each stage and their tools accordingly and have that integration and traceability.

But yeah, we're still in the design phase on much of the reporting and how we will aggregate data. But that's a heavy part. A big module of Venue.sh is to provide a lot of information to non-devs.

There's a large mix of these kinds of high-level or alternative personas. There's a bunch of high-level reporting and analytics and things in Venue, and there are also some of the Creative Hubs concepts, even like at the lower level in Backstage, whereas as a team lead, you might go on your team page, and you see here are all the like pull requests that relate to different team members, even in different tools. If you're working both on, say, GitLab and GitHub simultaneously, there's a home for that. There's like a persona for a product, a manager – where you look… If you're a project manager and you look at… OK, here are some things you might be interested in.

So there's a whole bunch of non-developer bits and pieces. I think of it as a development product of sorts.

This has been fascinating. It sounds like it adds value across an organisation, not just for developer experience but everybody's experience.

So well, that's a wrap for DevOps Decrypted podcast – you can connect with us on social media edit after this, and let us know what you think of the show.

For myself and Jobin, Rasmus, Jon and Mike, thank you for listening, and we'll see you next time on DevOps Decrypted – part of the Adaptavist Live podcast network.

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!