Hello, I'm Rob Hirschfeld, CEO, co founder of RackN and in your host for the cloud 2030 podcast. Today's episode is unusual in that you really should look at the video, we talk about backstage.io. And we have that conversation centered around a demo done by one of the RackN and interns, Xander Franks. He's been exploring with the backstage to Digital Rebar integration. And the conversation that results from that really explains backstage in some fundamental ways, and what it takes to build good developer portals. You will find in this episode, both the broader information about how to do integrations where you have a developer portal as a front end, and the key insights about how backstage works. So it's sort of a double benefit. To get the most out of the backstage pieces, you will definitely want to see the video which we will upload to YouTube and link in this podcast notes. Take time enjoy this whole podcast, both in video and audio format.
Xander is an intern with RAC and he's been looking at backstage for us. And Xander, I wasn't thinking to put you on the spot. But I forgot to put backstage on the calendar for today. And if you are willing to share your your work with a broader audience, I would love to hear what you have to say if not we can I don't hate I don't like putting people on the spot.
It's not super advanced or interesting yet, but I can certainly take you through and I have I would
love to see that. I think that would be really, really cool. If Martin cloths are you familiar with backstage because I can give a thumbnail of what it is and why we're playing with it? I am,
I am not. So I would, I wouldn't mind the elevator speech on it.
Backstage is a CNC F incubated project. That is it's not a Kubernetes project per se. It's a JSON. It was written by Spotify as part of their internal dev self service system. And so they wrote a platform that is basically designed for them to have developers build and maintain self service projects. It's written in think node TypeScript, as a platform. And it's radically extensible. So it's really a pretty minimal framework on its own. With sort of some patio, the ability to do an extension around it.
But it's almost sounds like platform engineering as a service.
It's it's platform engineering from the developer self service side, which is partly why we're we're interested in or we're looking at it doesn't do anything. Xander Xander, I think one of the things that we had to work out Xander, we'll walk through some of the scaffolding stuff where you actually give it a really simple set of steps. But it's not really an infrastructure thing, it's more of a catalog. So pretty minimal. This is the thing with a lot of platform engineering work, it's it's if you're just talking about Dev, the dev side of it, it's designed to be you know, pretty lightweight, by the purpose the devs just need a I need a cluster, go build it, you know, should follow spec, I don't want to spend a lot of time or have a lot of knobs. Whereas from the ops side, it's a totally different, you know, the experience has to be different. And so what we're looking at is can get backstage provide some dev UX that we can plug in on the back end. And from that perspective, it's generally the stuff we're doing I think is generally useful because assuming backstage continues to generate the interest it is then being able to plumb things into Backstage as a as a quick sort of Portal with a catalog for self service with you. I think a lot of companies are very interested in that. Yes,
they see the usefulness or not, sorry,
Martez. No. So
I see it in a similar fashion, but the way I see it in many ways, for for good or for bad starts to go back to the sink. pane of glass idea in which I need a portal to aggregate information, whether it be information about my services, information about my CI builds, it's in many ways it's becoming that place where, hey, I need to log in in the morning, and find a place in which I can sort of get that overall view of all the systems all the information I might need, as well as when you start talking about onboarding new developers or even in theory, new operations folks, or really, any folks from a technical standpoint to the organization starting to become some of that, that wiki that that confluence, people tried to make work, but never really got traction. And so, to Rob's point in terms of extensibility, that's where a lot of the major value is starting to be realized of being able to bring in information from external systems, and then aggregate that in a single place. Good, that's a good ad.
Call Center after your little bit of have you done more than a little study at this point, you have anything to add that we're missing?
I can't say I think I've been kind of looking at backstage from the perspective of developing a plugin. So I think I've missed a lot of the like, kind of important practicality of it. In that regard?
Well, that's I think, I think the the key question comes back to is it, you know, how hard is it to actually do the extensions? Um,
I think, for the most part, it was pretty easy. I ran into some issues, I think, so I wasn't familiar with yarn instead of NPM. They're using yarn. So it took me some time to get that to work. It's a little touchy in some spots. Some of the documentation isn't super clear, but I was able to figure it out after you know, just trial and error for a while. But for the most part, it's like aside from rough documentation, in some spots, it's it's really powerful. Like you can see all the immense things you can do with it. Accurate stuff, one spot. It's a cool way to have like a an extendable portal.
In water, you want to walk us through it. You did?
Yeah, sure. I just got set up. So awesome. See? Here we go. So I've got the backstage instance here. Do you see my screen right now? That's perfect. Okay, so I've got backstage here. First, I'll walk you through what I've done so far. And then I'll take you through how it works, how I set it up. So your request was to be able to create and spin up a cluster from backstage, I go over here to create, to get the templates, I added this create DRP cluster template, I can click Choose put in the endpoint. So I'm come over here and steal this endpoint. Awesome. And then I'll call it backstage monster and give it a whatever, broker doesn't matter, just in this case, needs to be able to get sent over to the ERP.
Okay, you haven't you haven't built the full class, everything necessary to start rosters start, okay.
And these fields are totally you can change them from within the template schema. So just right now, I just needed the baseline information to be able to spin up a cluster. So if I hit next step, it'll let me review what I've picked, and click Create. That'll show me what's happening. And I also added a little link here, it should say jump to cluster in the UX. That'll take us to portal dot RackN. Io, but I've got an open here and test. So you'll see it's, it's here. Now I'd
like to read this 179. Yeah, so just I'm looking at here's here's mine. This is backstitch cluster. I see I have my own version of that, that UX. Oh, I see.
But yeah, it's, it spins up the cluster now, which is pretty nice. And this would, I could think it could add more output here if you wanted to see more information. But right now this is just, it's just sending sending a, you know, route call, it's just saying, hey, post to this route, and it creates it. So the way this works in the back end, people with their own backstage instances can create templates, which is kind of what that create DRP endpoint page was. It's just specified in the Yamo. And then so you have the metadata for the template here, your parameters as to how the hell backstage builds that form for you. So I have this endpoint field, the name field, the broker field, of course, you could extend this with more options. And then steps is what actually happens when you run the template. So the action is this tip clusters create and the input, we're just giving it our parameters from the endpoint name and broker, and then that will call our DRP actions plug in this specific action. And this output, you can just have it linked to something so that's the templates part.
So so if I had a step that generated some information that I could I pass that forward to the Another step. Yeah, I believe
so. So this templating thing. I think it allows you to Yeah, you can pass information around. I think the parameters just steals from this right here. But yeah, I think I'm pretty sure you can totally see mostly pass stuff around that way.
Yeah, probably out photo steps. Sorry, there's probably an output insteps similar to the input.
This syntax reminds me a lot of concourse CI, where you where you assemble your, your jobs in a very similar manner.
Yeah, that's cool. So yeah, so we could Oh, wait, hold on parameters and point clusters in it? Yeah. You're You're assuming everything, it'd be nice. Center, it'd be cool to have an output where you like, picked up the UID of the cluster or something.
Oh, yeah, totally. And that should be possible, too. I think so actually brings me to my next point. So this plug in here, I've got this derpy action spec and plugin. Here's the actual action that handles creating the cluster. So it kind of redefines the schema of what inputs it expects. And then here's the real meat happens. It's this handler. This uses the TypeScript API that we just wrote. So we spin it up, we pass in our endpoint, which comes from this endpoint field that I just showed you in that template. The token gets set from the config of backstage and then all we have to do is just API that clusters that create and this is all auto
MasterChef, so
yeah, it's, it's, it's 30. So there's,
so there's one of the things you did was you built a Digital Rebar type stripe, which clusters is a core type for us create is a core verb, you're just passing information into that create. Okay. Interesting.
If I got rid of this, I think it my error, because it's expecting some. Yeah, it's expecting some output types that it's supposed to be familiar with. I'm not passing everything that's required to specify cluster because if I did something like, as can you say, Kant's cluster equals steal all this?
Let me do this. Now, I think we get autocomplete for UID. and stuff. So yeah, so Okay. Really easily see what what fields need to go into making an object?
Wow. All right. So and then, yeah, when I, when I was reading this, I thought part of what the handler allows you to do is you can return outputs. So I think outputs are part of the spec. You're just you're just not. Yeah, I
think you have this method here. And you can pass some value too, which is pretty cool. I think you can use that from the get go back to the template Yamo. I think there would be a template field like output dot foo, if I wanted to go in here and say output, u bar, kind of a thing. So yeah, I think then in that case, if this returns a looks like it returns a machine. So if we probably just come in here and do something like Oh, it probably wants us to do it. Maybe sorry, I'm not totally familiar with what, sorry, this used to be awaited. There you go.
Nice
output that and then we can even come back and get rid of this name thing here and just do
that. All right, that's cool. That's powerful. So so if this is where it comes back to if you have the API documented, building up a couple of methods like this make a ton of sense. Is there a delete? Did you did you have when you define the cluster here, I'm interested in what the scaffold looks like on this.
Okay, I think you'd have to add another action here. I haven't returned an array. So you could create, you could just copy this whole thing right here. This, I could call it delete. Code just needs an endpoint and new ID. And then only difference is going to be that now instead of reading view, await API dot customers dot Delete. I think it just yeah, you just pass in the UN directly CTS and put that in you it should be super easy to extend them.
The code completes really make this very nice. Yeah.
And I was looking into since this is so easy to write manually, I was looking into having some kind of Yamo file to easily map from backstage action ID to DRP. endpoint, the right route. Because that way, you wouldn't have to write any of this code out, you can just write a Yamo entry that would build this code for you pretty much. So that way you can instantly create,
right? So you would have derpy clusters, creating derpy clusters destroy you in pass, you wouldn't have to pass data between them. Ahsoka, so
as far as generating the actions goes, right. So like if we wanted to instantly generate backstage actions for every possible route of alerts or clusters from machines?
I say, Okay.
Interesting. Either way, it's super easy to add more actions. I think that just kind of gives us more, it allows us to batch create, like 10 new actions at a time. Okay.
Yeah, that does make sense. Although I, yeah, having having everything available. might be overkill. From that perspective. Oh, yeah. Totally. Sometimes having too much too many options can be confusing. And then was one of the things I was playing with is that there was a way to, can you jump back to the UX for backstage? Yeah, sure. This is really cool. You've done great work. Is there I was playing with a way to actually retrieve like all the clusters that you already have.
I think I think your work should be here. Yeah, right here. Okay. Oh, that code will be over here. I do this. That code is over in the separate plug in right here. This is the one that you'd written called Digital Rebar.
I believe. This is what you wanted right here. No, yeah, I just I just think it was dumped in a JSON object. But with the TypeScript stuff, you're like, that's literally what a DRP API a DRA API clusters list?
Yeah, I think I'd have to add the package reference for this plugin. But yeah, you could totally just map the type and it would give you all the autocomplete easily.
Trust Oh, and then you had to figure out how to put the token for the cluster into the config file. Okay. So this is going to be reference.
Actually, now that we have I have in my package dot JSON, I have the token in there. So if there's a way to grab stuff from the config from within this component, then we don't even need to pass the token anywhere.
There should be I would expect to
see, I'd have to check their documentation. I'm sure it's there.
Well, that would be that'd be cool to see. Because then after you've created it, the next steps would be to show that cluster on that list so that you can see what the clusters are and then just implement delete, because right now there's no How would you delete? You've created the one,
I think, I don't know if it makes quite as much sense to delete from, like a template like this, because this kind of implies that you're creating the from a template. But you could totally implement the delete the Delete action from the plug in that you wrote. Okay, maybe we could have a trashcan icon right here something that would kind of follow a similar workflow as the our UX.
Wonder if that's what somebody would expect? So you'd be oh, well, you would, because you're creating a new template, I built the template. Well, so the one that you Oh, this is this is creating a cluster, right? And then where it goes, who knows? Right, that's a different if to go back to the list.
So it's gonna depend on how you treat it. So take some example, something like ServiceNow, where everything is then the catalog, there will often be multiple actions in which I have a create action as a catalog item. And then I might have a delete or update action as two additional separate items. So it's really going to depend upon where you want the experience to go
through. What so what would that mean? I know we don't have a complete system here. Yeah. So we got
it would be like, say, where you have the Create cluster, you would have another one similar to it. If you treat it like a service, pure Self Service Catalog, you might have one that says Delete DRP cluster, and then you're going to have to then reference or look up existing clusters. One of the biggest challenges that that then becomes how you want to associate the references from a user stamp point. So what I mean by that is user comes in creates a cluster, who should have access to be able to delete that cluster? When I now go back in?
Right, right to permissions become a thing, or you need to filter it somehow.
You'd like to be filtered by permissions based on the user or exes they have. Yeah. So full disclosure, this is literally the type of problems to daily basis.
I'm glad you're I'm glad you're here that that's are you doing them in backstage?
No. So So company I work for Morpheus data is a self service platform primarily for infrastructure. And so we have our own service catalog that has things similar to this as well as we have integration with ServiceNow. And so oftentimes, I'm dealing with two types of catalogs and how to best expose that to end consumers.
Interesting, I think the only reason I'd be hesitant to have like a delete action here is because the header of this page implies you'd be creating something.
Yeah, and so that's where it gets tricky. And then especially if you had the list of clusters, then you'd have to do the filtering there of trying to figure out based upon a given user's level of access, or roll association or group Association, which clusters they should be able to delete or destroy.
If, if we built one say that had a timer on it, that automatically auto cleaned up. Like if we put a parameter in there, and you go back to the code that does the task, like we could create a trigger and a timer to do a removal?
You mean the the action here?
The action, I guess?
Yeah, you can pass parameters, whatever
parameters you want. So you could just put a parameter that that has the Delete after X days. And then And then we'd have a separate cleanup task. Behind the scenes. I'm just I'm trying to think because otherwise, yeah, you're gonna have this is what I haven't seen with backstage yet is I've got a catalog, I create something, somewhere, you're gonna want to say show people what they've created.
Yeah, so because the state management challenge, which is similar to what ServiceNow deals with, of, I've got an object or I've got a construct. And while I can click on certain things in terms of objects in ServiceNow, but to be able to actually manage them with the level of full fidelity is very tricky.
Gotcha. Without going to ServiceNow. You, me?
So even in ServiceNow, so I don't know that much about service. Yeah. So from ServiceNow standpoint, oftentimes, the, I think a lot of the initial idea was that a consumer would be requesting a thing, whether it was a mouse, a chair, a keyboard, whatever it might be. And typically, that's a one time transaction, there's no additional operations that need to be performed. And so if you think of it as that model, then when you're trying to introduce something that essentially is quote, unquote, stateful, it becomes very challenging from a UX perspective of, okay, I'm able to create something easily. I have information about what it is, but now how do I then interact with that given thing after the fact?
Right, that's a ServiceNow problem. Backstage is going to I my assumption has been that it was it was creating there, you know, people were getting resources or a Kubernetes cluster or something out of this, it wasn't just kick off my build process, like it was create a Git repo for me. Like, that's one of the examples they keep using a set up a project. Oh, I guess that's, that's, uh, not really stateful. If I'm, if my to do here is set up a project B project and get that one
time operations? Yeah. Then I've got the thing and I'm good to go.
Gotcha. That's why it's, that's why it's structured around the template initially, on what you're gonna do. Okay. Interesting.
Yeah, it's a challenging.
Yeah, no, it definitely is. And it's, it's interesting, because I had not thought through that use case, as much like the one and done use case. Like, give me a good you know, get up, get a cluster, you know, set the cluster up, handed over to me I'm done. I'll, you know, I usually assume people are going to clean you know, what automatic cleanup or whatever lifecycle for something like that. But you're changing my my thinking a little bit, which is good.
Yeah. And that's where it gets very interesting when you start talking about even the idea of things like IDPs or internal developer platforms, as well as even the overall construct of single pane of glass and Then even what we've seen from sort of a, an evolution of the idea of service now or not service now, but self service, in that, for the most part, the industry has been so much get commit, get commit, get commit. And then I think we're starting to see more and more as things get beyond those that are dedicated to git commit and get ops, that there is a need for something that is a lot easier. For those that may not be deep into Git ops and Git commits, I just want a thing. And when you think about from a pure value standpoint, to the organization, while as a technologist, it's interesting when we start talking about Git ops and doing things with Git commits, but ultimately the value to the organization isn't that you were able to do it with the git commit, it was that you were able to provide value to the business.
Last, right, but I mean, the thing we've talked about get ups and in the past, I mean, it's, it's, you still have to execute stuff behind the scenes from a GET UP sprint, just like this, right? This is only useful to the extent that you're going to define steps. And if the steps don't exist, you're going to have to know how to build the steps. And the idea of building like, you know, does it actually let me pause before I take it to the next the next question? That right, am I am I, this is building a mini workflow engine. They could cross systems. So you could assume you have inputs and outputs, you could start actually chaining something together with these inputs, but that at some point, that becomes really, really tricky, ugly.
Yes, it gets quite tricky. And then even in terms of even if it takes specifically this example here of how it's being done, whether it be done via direct API call, or maybe I might want to literally, somehow have backstage create a git commit, that then triggers the actual operation. Okay, so which is isn't uncommon, because I think that's actually how the service now and TerraForm enterprise plugin works, or the integration works is that literally ServiceNow creates a git commit in a git repository, and then TerraForm enterprise picks it up via the web hook, I've done something similar from a design standpoint. And so when we start getting into UI driven consumption, the lines really start to blur, in my opinion, of the the ideal practices that we might want to hold on to from a back end technology standpoint.
Well, the what you just described as is, like, I gave somebody a UI that builds a does a commit to a Git repo that's actually then doing triggers, like completely removed from that, that perspective, which is good, I guess, because the Git repo then becomes my source of the trigger. But that's that's, like, very disconnected. Systems, right? They're loosely coupled. This I think the
land depends upon your philosophy, one would argue, in a way, it's the best of both worlds.
Right, because you could you're saying because you've got a UX, that's, that's pretty and somebody can do that work. If they're not, if they're not ready, they can, or if they're more advanced, they could just go to get, and you're gonna get the right behavior either way. Yeah, in theory,
you're modeling the the exact same sort of behavior, except all I'm doing is just adding on a layer of UI, so to speak.
Each we've talked about Get, get hook polling versus web hook. And in the past, I think you were, I'm trying to remember if you were on that call or not, but
it becomes because very interesting, even in a scenario like this, where you might say, you know, what do would I even want to consider the idea of doing via git commit, and then it becomes, in a sense, less deterministic, because then I then have to reach out and pull the, the external system that's going to pick up that get some git commit to start performing validation of status
and then feeding that back and then this thing doesn't now now this is if you're going to get a list of that you're going to have to do that through the the other interface where you're getting the object and the object lists to see like the challenges you can't see it. One of the things that Xander you might have an answer for this I So how are the steps executed? Like, it looks like? Are they just done in the post? When you say template created just spins up a thread and runs that template?
Yeah, as far as I'm aware, I think it's just as soon as you fill out this information, it does this and the UI will show you what step it's on and the output of each step.
But but if I if I created a whole bunch of asynchronous or long steps that took time?
That's a good question. I'd have to refer to the docs for that. Okay.
I didn't see any threaded runner. For this, I mean, a web a web service will will thread to the extent that a pager response is going
is I'm curious if it's running in containers, given the reference that classmate to the steps similarities, like a CI system, it may very well be running each of the steps and containers like get up actions or a circle CI might
run it. Didn't I mean, this is a dev setup on Xandar. I'm assuming you did. I just did a dev setup. Yeah, this is actually the I haven't seen anything that has a has runners that are runner pool in it.
Okay, maybe I'm just skimming for any steps or run.
We're not in configuration, but I haven't seen anything in the past talking about it. It's like a database and seems like you know, you would not want to build very big orchestrations with this. And there's no I don't I didn't see any logic either. So it's it literally is a sequential step sequential steps. Yep. Yeah, right here. This would be something that I assume they're scaffolder is going to grow over time to say they progress. I am really intrigued by the idea of having the decoupled event system, right where where you do something here, but it's really triggering something that has an event that's going to cause something alright, that's there's a chain as chain reaction.
Yeah, because then might say potentially, it gives you a an additional degree of reliability. But in theory, it doesn't because mean, but could be even with your API call, you can add in logic to be a little more resilient in terms of the API call.
Right? Well, hopefully, if it if the call fails, it would actually Xander Can you can you build a step that fails? Or make the step you've got failed to so we can see what what how? Yeah, I
should be able to let's Jarius let's just throw perfect.
See if that still builds
on this shouldn't matter. You have a get a point message. I didn't give it a message if I think if I had passed something in here.
Alright, so yeah, so if it if your API fails at some step, you're gonna have to deal with whatever the cleanup is, but we're gonna come back. It's just like any any other. Hey, look at that.
Very nice. Yeah, I think for templates with more advanced, like, greater amount of steps, then. Yeah, you could, it should definitely show you what step it's failing on this one. It's kind of a bad example, because it's one single step. If I think if I checked this there, this is the provided template. I think this one might have multiple steps.
Makes sense for the example to you. This actually tries to get to get up. Yeah. Yeah.
Don't even click around between steps two and see individual outputs. That's nice.
All right. This is the answering my question about what what happened, you're still might have a rollback problem from that perspective, but I think I think we come back to the idea that I might have to, I might want to have a system that does a deeper orchestration behind it.
Yeah, because in most cases, you're just just making that single API call. But also theory in terms of that the rollback problem you're mentioning is would be, you could add in logic, to obviously do a conditional. If there's a failure, then run this particular API
call to delete the cluster So that way, it's not, hey, it failed that you gotta go clean up yourself.
I haven't seen that yet, but I haven't dug as deep. Yeah. And Xander Sanders pulling it up. I hadn't seen any rollback or cleanup logic in this in the spec
said to be the case. If you haven't built it yourself, we're likely similar how standard added the throw command, you would do the API call? You would catch it inside your code.
I thought you were saying from within the template? Here? Yeah,
I did I did to Xander it's
yeah, there's not enough conditional logic in the steps. So you'd have to embed it inside your call in a single step.
Which is now we're now we're getting into custom custom steps, specialized steps, right.
But in theory, the, the clean up, quote unquote, or rollback would probably be a function that you would be able to inject to various different steps that you might have a multi step process. Doesn't make it easier, but
it's interesting. The other the other thing to do would be to collect to do steps that collected information. So you could you did still potentially want to you're still gonna have a cleanup prompt. So the what I'm thinking is like if you had before you create a cluster and the example we have, you might come in and have guide somebody through two or three inquiry steps saying, hey, there's there's this and then you need some information from them, then do the next step and then do the next step. Interesting. But yeah, it's simple.
You know, I'm wondering if it would be possible to create an action called like fallback or something that lets you, you pass in an action that you want to try and then a fallback action to fall back to if that action fails. So that way, you don't have to embed the catching within an action handler, in case you're using a third party action, it doesn't have that kind of fallback technique that you want to use.
There would be a schema extension from a backstage perspective, right? That would be I wonder if the community is thinking about that? It's it's I mean, it's, it seems like a not wouldn't be would would be a pretty I would expect it to be a pretty common use case. But I guess I'm thinking like a building something and it doesn't always doesn't always work. But it depends on you're looking at your
visit how you would go about it. Because in theory, I might just create since the superset of the API, and I handle the logic on the system that's being called
as opposed to in Backstage itself.
Right now that's, I think, I think the question you're getting to is how much is in isn't backstage? How much is in the back end?
Yeah, it's the classic challenge of anytime you do some orchestration? How much? How much logic do I try to do in the calling system versus the actual underlying system?
Do you ever do a rule of thumb if you've been doing it for a while.
So usually, mine is going to be starting off with the best tool for the job. If I have to think really, really hard about how I'm going to orchestrate or handle it in the calling system. If the calling system isn't equipped to do that, I'm just going to embed it or push it down further into a point where I feel comfortable. An example might be like a self service platform calling Ansible, the self service platform doesn't have great orchestration, I might move most of the logic down into the Ansible script or the automation, handle it there, and then just keep it in there as opposed to try and handle it at the higher level. The other thing that starts to also do is start to potentially allow me to decouple the two components, because at some point, I might say, you know, I don't want this UI component or this UI way. Or maybe I do want to do some additional testing of the orchestration outside of the UI. And it might be handed to a an individual that wants to test it on their local system or evaluate it. So those are usually the areas I start to get at is best tool for the job and then also start to consider can I test it outside of the UI component?
That makes a lot of sense. Or even exercise? Yeah, tester exercise. So that right, so that that comes back to this is almost entirely UX. There's no There's no non UX way that I'm seeing to drive to test your scaffolding. That's that would be, that'd be an interesting. Right? You're we're literally going through and every time we want to do a test, right, I'm Xander, I'm assuming you're you're, you have to poke it through the UX. Yeah.
So back back to Martez point. That's the way this is going to be structured is you're going to end up doing pretty much its forms and handoff to a back end system. Okay. That's it. That's there's plenty of back end systems. This is a reasonable, right? There's no sense in turning this into an orchestrator. It's, it's right designed as a catalog.
Yeah. And it keeps that consistency when you talk about debugging issues of literally, if the front end UI is literally just passing making the API call similar I could do with the curl command or PowerShell, or Python, then I can easily debug and test of, hey, if it's not working in the UI, what's going on? Can I replicate the same issue at the command line and completely remove the UI component as a possible issue?
That's an actually an interesting idea from a logging like in the logs that are generating is it or is it do you know if if it's possible to dump things into the logs that it puts out? You get well yeah, you because you could also in when you built that template, it actually showed you output from each stage. Oh,
you mean over in the template and backstage or sorry, the algorithm back? So
you created you created the cluster? And it gave you feedback at each step? I could actually tell you could actually tell people.
Yeah, looks like we can do through here.
Okay, so you could say, Hey, I'm going to tell you Yeah, creating cluster, you know, this is the JSON or this is the right.
This is nice.
No, okay. No, it did it gave you the first one. I think
the UID change I had made it's not fond of, I'm gonna have to Oh, you need no way. That's the problem. It's not there yet. I think I might have to run this, Jason first, to actually decode the body. Okay, let's see if that does anything.
Plus, you've been quiet? What? What are you thinking? That you're fresh eyes?
Oh, I'll just talk a little bit out of my comfort zone. So I've been mostly listening to what Martinez has been saying. It like my perspective on this is like looking at biccies japonesa potential internal dashboard.
I mean, there are certain requirements that that I would have in my particular situation that are not necessarily universal, universally applicable. Things like ensuring that like certain services, or certain resources are available to some users or not. The other ones are the capabilities, etc. So I mean, at least for for my specific purposes, I think backstage is probably too young of a project to be useful. But then again, like, I have a long shopping list, I'm comparing this to perhaps some of my, some of my previous positions where, where I was working with startups. It would certainly make more sense then to be able to give developers basically like a one or two clicks, kind of self service dashboard for creating, like infrastructure for, let's say, test environments and so on. I would have to play more with it though. So, which is kind of why why why I've been mostly quiet to that guy. I don't know enough about it yet to have a strong opinion.
That makes sense. That's why I was just weird. You know, this for us is a discovery discovery sprint. Did you recover? Xander? Did you just recover that?
I refreshed and I think the temporary log that had been created through an error. So refresh it again to get rid of that
you're gonna bump into a naming collision. did create it,
didn't it? Yeah, it's
sorry, I this is my cluster in the background. So it's, it's I'm watching I have my own UX into it
should fix that problem. That's
funny. Jays probably already failed
to start over
button. Yeah. That's that that's actually an example of building a step that says confirm, hey, look at that.
Saying I got it to work here. Only problems, I have to pass this format JSON thing, which means I'll have to come in and update our cogen library to fix that. Do that in here instead.
So that's for us. That's one of the takeaways with this is that having a TypeScript library is super handy. If you're well versed in TypeScript, if if you're that's this is where Xander is working at lightspeed compared to what I would have been able to do from a demo perspective. That's really, it's really cool, though. But I really liked the idea that somebody can come back and just say, Yeah, you know, what I'm, I'm, you know, I don't want somebody to have to see all the operational details, just give me You know, I just need to create a cluster, or I just need to do take this operation. We had we have, we have a couple of use cases that are like that, that are just more narrowly defined, it gets extra cool. If somebody's already invested in backstage, that's and this, to me is where it gets, the thing gets sort of interesting, if somebody already has backstage, then you can give them a scaffold, and then they can build this inside of their current system that becomes that day, you get the cataloging effect. Yeah, the challenge that I see
at the moment, it's classes why and, and I think it's going to continue to grow. But is that is that it is open source. And since the unsupported so to speak, and you start talking about enterprises wanting to invest a lot of time and energy
into it. I actually don't see that being too much of a barrier. I mean, particularly for internal use, open source software is not that much. looked down upon or, or, or even like the lack of a strong sort of, like support, contract like it, again, looking at it entirely for internal internal use. If you have a little bit of downtime on need to restore it without an SLA, it might still be appealing to a lot of companies. But particularly when you're dealing with a regulated industry. Then you there's certain features again, like things like audit logs like having multi tenant like access controls and so on that become nearly I must admit in most cases
Yeah, but that's I my takeaway comes back to the same thing, it's it. It's, this is in connecting into his system that does the access control and the audit logs and the orchestrator, it's, it's just a, it's a, it's a front end the barrier, like if I'm, if I'm building a project, and I want to give somebody a front end, you're you don't, you're not, you're not violating the back end, hopefully, you're not violating any of the back end contracts, you're just making it easier to access some.
Well, so if we take the cluster as an example, so similarly, it's going to be done is backstage is going to act as a broker and then utilize a service account. To actually fulfill that request, you're going to have to ensure that the role based access control is handled on the backstage side, because you're making an automatic assumption from this case directly inside that any request that comes through as the quote unquote, backstage service account has been fully addressed from an auditing standpoint in backstage, as well as from an access standpoint to what somebody can or cannot provision.
Yeah, but their user needs to needs to either identify to the back end, in which case, the front end needs to have to do capability of providing that information. Or the user needs to authenticate with the front end on let's say, via SAML, or, or some other information, or some other authentication method like that. And then you the front end connects to the backend under that assumption on the front end is authorized to make a request on behalf of the user.
It's like there's a permission model. So it might be
this is that yeah, I mean, and this is one of the things that no, Xander ended up having to do some research on this. The it's, it's a little tricky from that. Like, it's not I agree with your you on the cautions. As far as act, you know, who's who's under whose authority are you making the request right now you're, you're, we're, we've got a token, API token. That's, that's interacting with Digital Rebar. So you're right, everything's coming through, under backstage, the backstage sights authority. And to make this really work, right, you, you'd want to have the pass, you'd want the user's authority to pass through, or you want to have some some additional way to say, for this user, I've got these I've got the secrets.
If I'm not mistaken, there's a user advocate here that we could somehow pass information into, I'm assuming with, you know, integrations or, or something of the sort. I don't know how to add custom integrations, that isn't the problem. But I think that would be the solution. If we wanted to go from like a, like a front end model to have the users authorized themselves, and then send their information through our API.
I mean, you could do a pass through if there was likely to be a desire for that same user to log directly into racking, but if you never see a scenario where that user needs to log into rack in, and backstays will always be the front end. In theory, unless there's a heart requirement, you could continue to use the service account. Just make sure you're doing proper authentication and authorization and auditing in backstage for that given user.
The verb we have, we have some of the ways that we we could handle things like that is that Digital Rebar can be distributed. So you can actually create a endpoint that was you know, when that right now the way Xander is doing it is bring your own endpoints, so you provide endpoint and you might be providing just the ones you have permissions for. So so I have to figure out the token token off issue
they'd have to provide their token with the the endpoint when they had the endpoint
username and password let's just not not either either one of them right at that point your credentialing the call in the in the in the template but these are very you know, these are these are tricky problems for any self service portal because you're effectively spanning your front ending another system. Yeah. Cool Xander, I really appreciate you being gone on the
spot for us. No problem.
This is this is fascinating, fun to watch your code a little bit too. Boy if our tests I really appreciate your insights. On this, I think having, you know, actually coming back and saying, Alright, yay, cool, I can create something within the huge, but that comes after that of how to think through the architecture is important too. So this was really helpful and insightful. Thank you.
Thank you, Sandra for showing us this. And also the same thing. Thank you, Martez, for giving us giving us your insights. I'm also wondering, like what other tools like what are tooling would fall under the same category where there always is or not? It kind of feels like, similar to, in some, in some ways to things like run the Octopus Deploy. Just trying
to, it's more of an aggregator than those. So you're literally talking like somewhat in the space of a service now in terms of service catalog capabilities. But it looks to also provide things like technical documentation as like a wiki really becomes that single pane of glass that most have shied away from. So CMPs, or cloud management platforms sort of fall into an adjacent space, which is the company I work for, is classified as a cmp. I know manage IQ was one of the ones that redhead at bought, and no Ansible automation platform from the Ansible Tower is doing is starting to hit more down the the Self Service Catalog route. And so there's a bit of obviously a focus towards some of that self service catalog, but also just broader information aggregator in a sense,
I would I would put potentially, like cloudify or space lift in the
Okay, so there's a bunch of names there that that do recognize. So it but I'm actually surprised that the answer one is going in this direction. But I guess I've been I've not been paying much attention to it lately. So I have some catching up to the yeah, they're
they're trying to scale automation across the enterprise. And similar to what we're seeing here. From this, this example, for those that are not knee deep in a particular technology, having a easy button is super useful.
Wonderful. Thanks.
Everybody. Appreciate the time. Thank you. Yeah, thanks. Oh, Rocky. Sorry, I didn't see you. Miss. I miss letting you in. There. Yeah. Next time. Hello, how long you've been?
It's not a problem. I got in late. I just wanted to see what was going on and, and say hi to everybody and say I'm not dead yet. Good. I will not flooded yet either.
Good. All right. Stay dry, so and dry. Yep, I'll talk to you seniors.
Happy New Years, everybody, I
hope you enjoyed this podcast. If you're listening to an audio, please do go check out the video, you'll get to see the code. And if you just listen to the audio, I hope that our times, watching and looking at Sandra code were not too boring or out of context for you in the broader pieces. There's a lot of great information exchanged in this podcast around the discussion of what we saw, I know you got some value out of it. If you want more and to hear more, do demos, bring ideas, please join us at the 2030 dot cloud, we would love to have more episodes like this. They are really what we enjoy seeing more of and discussing. I'll see you there. Thank you for listening to the cloud 2030 podcast. It is sponsored by rackin where we're really working to build a community of people who are using and thinking about infrastructure differently. Because that's what rec end does. We write software that helps put operators back in control of distributed infrastructure, really thinking about how things should be run, and building software that makes that possible. If this is interesting to you, please try out the software. We would love to get your opinion and hear how you think this could transform infrastructure more broadly, or just keep enjoying the podcast and coming to the discussions and you know, laying out your thoughts and how you see the future unfolding. All part of building a better infrastructure operations community. Thank you
