I think some overview would be helpful here. For example, what is it you're building? Why are you installing a scaffolder? That's next level. (Hey, I thought Backstage was just going to show me my doc tree...) After watching a couple times, I finally get what you're doing. And I look forward to your next post.
Thanks for another great video! My opinion about backstage has always been like going to the dentist, you don't go unless you really need it. Now that I saw what it takes to fill in a template and make it visible in a gui it's more like going to the hospital! There is though a lack of true alternatives to commercial developer portals, which may drive people to consider the effort to have Backstage in house. I still think that port is my way to go, and whenever one may need such a customisation level that it's not covered by port maybe I'd rather consider the option to build a developer portal from scratch in house
Nice presentation. Maybe a few points worth mentioning from a person using it for some time. - 90% of the companies prefer reinventing the wheel (I call it the salesforce syndrome) so instead just reusing the scaffolder components and actions, they make custom actions which they forget to maintain. Which is a real PITA and basically defeats the purpose of the scaffolder (let's be honest, if you don't want to have reusable components, writing forms from scratch is way faster). - on the other hand, the scaffolder components are very basic and so if you want to have dependent inputs (say the first one is a country selector and the second one, city selector, fill based on the selected country), you have to make them custom. So there goes your time savings of using a framework ;-) - debugging problems with the catalogue is a toss-up since error reporting is terrible (basically they tell you that the proble is SOMEWHERE in the tree rooted by a given locator) - backstage has many dependencies (both child and peer) and once soemthing goes wrong, there goes your personmonth of work - when you think about it, backstage doesn't offer much beside these systems for managing these two things. So it this is not what you need, you'd better steer clear of it
Backstage is great once you wrap your head around it. Definitely go deeper! Hopefully you can do a video showing integration of k8s, and other frontend plugins, and maybe the auth plugin and permissions. Just a small tip use the redhat permissions plugin and not the vanilla permisions framework if you dont want to suffer!
k8s plugin is, probably, the worst representation of Kubernetes resources I ever saw. It makes me feel bad to put it into one of the next videos since that would result in a long rant how bad it is and how whomever made it does not even understand how Kubernetes works.
@@DevOpsToolkitthere are other plugins in this area like argocd, flux, kiali, linkerd, topology, tekton, kubescape (in development) and more which depending on the need can be better
@vrabbi that's true. Some plugins are better than others, just as with any other tool based on plugins or other types of extebsions (e.g. Jenkins, terraform, crossplane, etc.). The problem, however, is that i think that backstage has a higher number of bad ones that other similar extensible tools. I think that a big reason for that is that many of those contributing plugins do not have an interest to do it well since their UIs might be competing with backstage on some level. Kubescape, for example, does not have an interest for you to see much in backstage but, rather, to click a link that leads you from backstage to their UI. In those cases, backstage converts itself from being a developer portal where devs can do and see what they need to do and see to a glorified collection on links. That might be the main use case of backstage in practice but, at least in theory, it is supposed to be more. Exceptions are those that took plugins seriously. I haven't spent much time with tanzu plugins or backstage distribution so I might be wrong when i say that it looked much better than many others. That might lead me to believe that backstage is more of a base for other vendors to build a frontend of a platform than to be used by people directly. P.S. I am not blaming kubescape for a bad plugin but only used them as an example that applies to many others, and mostly because you mentioned it.
Thank you Viktor, I'm very interested in backstage and would like to see more videos about it. Essentially how to setup application templates and go through the whole CI/CD process. User creates app from template, submits code, it gets built, then it gets deployed on k8s.
Backstage is amazing, once you wrap your head around the custom actions, steps, and plugins, the sky is the roof. What I found useful is to keep it simple, don’t integrate super complex logic into it unless you got no choice. Learn to delegate heavy lifting to satellite services.
i was in a huge argument with one about this, because i think it is also a very fine line, since you dont want to reinvent things that Backstage already does. Backstage has a few very good abstractions when it comes to interact with GitHub, Gitlab AzureDevOps etc. so the SCM integration is mindblowing great. so i agree the coupling should be from a Backend plugin to some satelite service
The next one is almost done and should go live in a week or two. It won't be advanced but focused on packaging backstage into container images and running it in kubernetes. That is a prerequisite for more advanced topics I'll explore later.
Thank you for the quality content you are putting out all the time by the way Victor! 😍 This series of videos is particularly interesting for me since im the service owner for container technologies in our unit. and i have been looking at backstage for while to build an IDP. But its a pretty big commitment i feel.
To be clear, I don't think you can build an IDP using backstage alone. What you can do is build a frontend (or a portal). Much more is needed for a developer platform.
This is an approach we are looking to adopt in my organization. We heavily rely on our own k8s written operators for self serving of namespace, clusters, cloud managed services and so on but it still requires cloning the repo and going through the motion of copy pasting and existing resource definition or writting it from scratch. I would like to see what you mentioned on the tail end how to integrate argo possibly to show the state of the resource once the resource has been added to the catalog. We leverage argocd as well from syncing of the source repo to our cluster with the operators running and acting on the resources.
I'm working on a video that explains that. In the meantime... That's very problematic since backstage is mostly focused on showing static files and not statuses at runtime. Both the kubernetes and argo CD plugins do not help much since they are very bad.
@@DevOpsToolkit yea, I agree. I haven't see anything extremely useful from the argocd plugin. On the other end we developed a backend web api that lives in our k8s cluster and queries resources for the status via url query parameters as well which in theory we could integrate backstage with possibly. But an out of the box or opensource solution would be nice.
@gerardocorea true. You need some kind of an agent in a cluster that provides information you need and a backstage plugin that fetches that info and presents it on the screen. You can go without the agent as well if that plugin contains all the logic to get what it needs from kube API.
I already started working on a next one related to Backstage and, unfortunately, it won't be about auth. I'll do my best to do it in the one after the next.
Love it. Thank you! something that interests me is a component hierarchy and permissions. For example DevOps would want to control clusters and platform services. Devs would like to deploy applications to those clusters. How do we represent/manage that hierarchy in a sensible fashion including the accompanying permissions.
I would love to see how ldap authentication is added so that you can then manage who has access to a self-service environment so that they can spin up resources in development environments.
This helps along, it is definitely difficult to understand backstage, quickly like within a day, until this. Would definitely love to see more about backstage from you.🎉
That video was super helpful, thank you so much! In a previous talk about "dumb" portals, you demoed port's ability to inspect the cluster's etcd to dynamically discover entities by looking for crossplane CRDs. Is this approach also possible with backstage? Looking at the docs I think I see elements mentioning that, but I'm not entirely sure...
I don't think that's possible with the existing plugins. As a matter of fact, it's not even possible to represent "basic" Kubernetes resources in a decent way. Kubernetes support in Backstage is bad. That being said, you can make Backstage do anything you would like it to do, but for something like what you described you would need to create your own plugins as well as a Kubernetes controller that would work in tandem with it.
@@DevOpsToolkit I think I found something, albeit not directly with backstage: it seems kratix is able to populate a bucket with backstage definitions from their promises. I stopped following kratix when crossplane introduced composition functions, but maybe there's something to look into there?
YAML key with no value is absolutely valid YAML. If it doesn't have any value, the value is considered as "null". The rest of the video must be quite confusing for people that don't know anything about Crossplane.
I kind of love it and hate it at the same time, but I think it is worth it to have Backstage as the only source of truth. I would love to see Argo and Argo workflows next, followed by Kubernetes runtime information.
so much work , so little value . as you mentioned: it’s instead of writing a yaml manifest file in your repo. and if all that trouble with the github plugin and the manifest creation is to asssit a developer not to write yaml and push it to hithub- if git commands are something this developer cannot handle - maybe he is in the wrong profession? 🤔
Why do engineers have to go through the pain of backstage when the same can be done via CI pipelines or, even better, Taskfile + CI pipelines? Just to have a GUI? If yes, then i would say no to backstage. When engineers get used to GUI they aren’t being engineers, they are just being tool users. Especially the folks new to IT world shouldn’t be working on GUI driven tools if they want to become engineers.
Almost everyone uses some UIs. I, for example, use vs code, grafana, k9s, and quite a few others. The question is not wether we use GUIs but rather for what. In my case, they are much better for observing something that performing actions or writing code.
@@DevOpsToolkit Yes, for what we are using GUI is the key. I agree with you. For analytics and visualization, something like Grafana is good. But for writing code, it should be “writing code”, not clicking buttons and all that. Clicking buttons instead of writing code, doesn’t make us engineers. In Backstage scenario, whatever it is doing, can be done easily with Taskfile & CI pipelines by doing some abstractions and letting the pipelines take care of storing the data into DB as well. This way Grafana can be used as UI for visualization purpose to see and navigate and click what’s required from Grafana itself, while the actual engineering work can be done by writing automation code in VSCode by leveraging Taskfile & some CI tool (like tekton or gitlab, etc.). We already have a ton of tools to use, adding backstage to the list is just extra burden and more over just makes lives complex. When things can be done in a simple way, why make our lives complicated!!
@@DevOpsToolkit all the tools someone is building is to solve some problem, but they all come with one caveat, i.e., they are built as opinionated. Of course, there will be some opinions when developing a project. But in DevSecOps/platform engineering world, the core principles are common for any tools which fall under that categories. So, if everyone have one common way of developing tools into one framework, the world will be so easy, especially when dealing with knowledge sharing and handling securities. I strongly believe and also demonstrated many times at the companies I worked for, the tools can be built simply by using a minimal utilities with the combination of CI pipelines without compromising security. Maybe i should do a framework and demonstrate in the public how that’s possible (if i find time, lol). Anywho, my point is, CICD system is very powerful, a lot can be achieved just by leveraging that concept itself. Lot of folks think cicd is just automation pipelines, but it’s more than that. One can build tools/solutions when a right agnostic CICD tool is selected to use (something like tekton), to solve many problems, especially developers portal related category.
Backstage is a hub for all things dev. It is also extensible, with plugins contributed by various companies. The fact is that many companies do need this. The question is not why they need it, because they do, but rather why are they building it themselves.
Thanks for always coming back to Backstage and never giving up on it 😅
Yes, eagerly waiting for the next session.
Thank you ! Keep doing more videos of Backstage 🙏🙏
Thanks alot victor that you got time to explore backstage. Really looking for more sessions.
I think some overview would be helpful here. For example, what is it you're building? Why are you installing a scaffolder? That's next level. (Hey, I thought Backstage was just going to show me my doc tree...) After watching a couple times, I finally get what you're doing. And I look forward to your next post.
I am scared to death, but still here. 😋 Keep it coming, please. Thanks, Viktor.
Thanks for another great video! My opinion about backstage has always been like going to the dentist, you don't go unless you really need it. Now that I saw what it takes to fill in a template and make it visible in a gui it's more like going to the hospital! There is though a lack of true alternatives to commercial developer portals, which may drive people to consider the effort to have Backstage in house. I still think that port is my way to go, and whenever one may need such a customisation level that it's not covered by port maybe I'd rather consider the option to build a developer portal from scratch in house
Great video! Good to see you helping folks on their first steps into the Backstage world!
Yes, more backstage videos
Nice presentation. Maybe a few points worth mentioning from a person using it for some time.
- 90% of the companies prefer reinventing the wheel (I call it the salesforce syndrome) so instead just reusing the scaffolder components and actions, they make custom actions which they forget to maintain. Which is a real PITA and basically defeats the purpose of the scaffolder (let's be honest, if you don't want to have reusable components, writing forms from scratch is way faster).
- on the other hand, the scaffolder components are very basic and so if you want to have dependent inputs (say the first one is a country selector and the second one, city selector, fill based on the selected country), you have to make them custom. So there goes your time savings of using a framework ;-)
- debugging problems with the catalogue is a toss-up since error reporting is terrible (basically they tell you that the proble is SOMEWHERE in the tree rooted by a given locator)
- backstage has many dependencies (both child and peer) and once soemthing goes wrong, there goes your personmonth of work
- when you think about it, backstage doesn't offer much beside these systems for managing these two things. So it this is not what you need, you'd better steer clear of it
Backstage is great once you wrap your head around it. Definitely go deeper! Hopefully you can do a video showing integration of k8s, and other frontend plugins, and maybe the auth plugin and permissions. Just a small tip use the redhat permissions plugin and not the vanilla permisions framework if you dont want to suffer!
k8s plugin is, probably, the worst representation of Kubernetes resources I ever saw. It makes me feel bad to put it into one of the next videos since that would result in a long rant how bad it is and how whomever made it does not even understand how Kubernetes works.
@@DevOpsToolkitthere are other plugins in this area like argocd, flux, kiali, linkerd, topology, tekton, kubescape (in development) and more which depending on the need can be better
@vrabbi that's true. Some plugins are better than others, just as with any other tool based on plugins or other types of extebsions (e.g. Jenkins, terraform, crossplane, etc.). The problem, however, is that i think that backstage has a higher number of bad ones that other similar extensible tools. I think that a big reason for that is that many of those contributing plugins do not have an interest to do it well since their UIs might be competing with backstage on some level. Kubescape, for example, does not have an interest for you to see much in backstage but, rather, to click a link that leads you from backstage to their UI. In those cases, backstage converts itself from being a developer portal where devs can do and see what they need to do and see to a glorified collection on links. That might be the main use case of backstage in practice but, at least in theory, it is supposed to be more.
Exceptions are those that took plugins seriously. I haven't spent much time with tanzu plugins or backstage distribution so I might be wrong when i say that it looked much better than many others. That might lead me to believe that backstage is more of a base for other vendors to build a frontend of a platform than to be used by people directly.
P.S. I am not blaming kubescape for a bad plugin but only used them as an example that applies to many others, and mostly because you mentioned it.
This is great, Viktor!
Thank you Viktor, I'm very interested in backstage and would like to see more videos about it.
Essentially how to setup application templates and go through the whole CI/CD process. User creates app from template, submits code, it gets built, then it gets deployed on k8s.
That's great to hear. Adding it to my to-do list...
Backstage is amazing, once you wrap your head around the custom actions, steps, and plugins, the sky is the roof.
What I found useful is to keep it simple, don’t integrate super complex logic into it unless you got no choice. Learn to delegate heavy lifting to satellite services.
i was in a huge argument with one about this, because i think it is also a very fine line, since you dont want to reinvent things that Backstage already does. Backstage has a few very good abstractions when it comes to interact with GitHub, Gitlab AzureDevOps etc. so the SCM integration is mindblowing great. so i agree the coupling should be from a Backend plugin to some satelite service
awaiting for a next backstage session(s)
More more more. Excellent explication
Yes :-) more backstage!! thanks
Another good video. Thank you so much 🙏
Personally, I would like to see another video about it in a more advance way
The next one is almost done and should go live in a week or two. It won't be advanced but focused on packaging backstage into container images and running it in kubernetes. That is a prerequisite for more advanced topics I'll explore later.
Yess🎉🎉 Very useful. Please show more!! Especially the integration of Argo sync status or cluster logs and metrics would be very interesting
Thank you for the quality content you are putting out all the time by the way Victor! 😍
This series of videos is particularly interesting for me since im the service owner for container technologies in our unit. and i have been looking at backstage for while to build an IDP. But its a pretty big commitment i feel.
To be clear, I don't think you can build an IDP using backstage alone. What you can do is build a frontend (or a portal). Much more is needed for a developer platform.
@@DevOpsToolkit Backstage provides a frontend UI right.. do we still need one more UI wrapper on top of it?
I'm not sure I understood the question.
This is an approach we are looking to adopt in my organization. We heavily rely on our own k8s written operators for self serving of namespace, clusters, cloud managed services and so on but it still requires cloning the repo and going through the motion of copy pasting and existing resource definition or writting it from scratch. I would like to see what you mentioned on the tail end how to integrate argo possibly to show the state of the resource once the resource has been added to the catalog. We leverage argocd as well from syncing of the source repo to our cluster with the operators running and acting on the resources.
I'm working on a video that explains that.
In the meantime... That's very problematic since backstage is mostly focused on showing static files and not statuses at runtime. Both the kubernetes and argo CD plugins do not help much since they are very bad.
@@DevOpsToolkit yea, I agree. I haven't see anything extremely useful from the argocd plugin. On the other end we developed a backend web api that lives in our k8s cluster and queries resources for the status via url query parameters as well which in theory we could integrate backstage with possibly. But an out of the box or opensource solution would be nice.
@gerardocorea true. You need some kind of an agent in a cluster that provides information you need and a backstage plugin that fetches that info and presents it on the screen. You can go without the agent as well if that plugin contains all the logic to get what it needs from kube API.
I love it but I also hate it sometimes. And yes, more on runtime information would be great!
Hey VIktor, thanks for this fantastic video. If you can do a video for auth plugin and permissions next, that would be awesome!
I already started working on a next one related to Backstage and, unfortunately, it won't be about auth. I'll do my best to do it in the one after the next.
@@DevOpsToolkit Thank you! 🙇
Love it. Thank you! something that interests me is a component hierarchy and permissions. For example DevOps would want to control clusters and platform services. Devs would like to deploy applications to those clusters. How do we represent/manage that hierarchy in a sensible fashion including the accompanying permissions.
Adding it to my to-do list...
Mulțumim!
Thanks a ton
I would love to see how ldap authentication is added so that you can then manage who has access to a self-service environment so that they can spin up resources in development environments.
16:58 "...After backstage... Kubernetes is simple...."
Based 😂😂
Thanks
This helps along, it is definitely difficult to understand backstage, quickly like within a day, until this. Would definitely love to see more about backstage from you.🎉
Thanks a ton.
Thank you....going further is the better option...create a playlist only on backage, that should suffice all devops needs...end of story
That video was super helpful, thank you so much!
In a previous talk about "dumb" portals, you demoed port's ability to inspect the cluster's etcd to dynamically discover entities by looking for crossplane CRDs. Is this approach also possible with backstage? Looking at the docs I think I see elements mentioning that, but I'm not entirely sure...
I don't think that's possible with the existing plugins. As a matter of fact, it's not even possible to represent "basic" Kubernetes resources in a decent way. Kubernetes support in Backstage is bad. That being said, you can make Backstage do anything you would like it to do, but for something like what you described you would need to create your own plugins as well as a Kubernetes controller that would work in tandem with it.
@@DevOpsToolkit I think I found something, albeit not directly with backstage: it seems kratix is able to populate a bucket with backstage definitions from their promises. I stopped following kratix when crossplane introduced composition functions, but maybe there's something to look into there?
@ChewieBeardy kratix Is a noce project worth checking out.
Ok, I hate it, but also want to learn more. WFT is going on here?
It's "Stockholm syndrome" :)
More is coming...
@@DevOpsToolkit funny thing it is even a Swedish technology
Like Ikea smart light bulbs that work only at random intervals?
YAML key with no value is absolutely valid YAML. If it doesn't have any value, the value is considered as "null". The rest of the video must be quite confusing for people that don't know anything about Crossplane.
I kind of love it and hate it at the same time, but I think it is worth it to have Backstage as the only source of truth.
I would love to see Argo and Argo workflows next, followed by Kubernetes runtime information.
so much work , so little value . as you mentioned: it’s instead of writing a yaml manifest file in your repo. and if all that trouble with the github plugin and the manifest creation is to asssit a developer not to write yaml and push it to hithub- if git commands are something this developer cannot handle - maybe he is in the wrong profession? 🤔
Why do engineers have to go through the pain of backstage when the same can be done via CI pipelines or, even better, Taskfile + CI pipelines? Just to have a GUI? If yes, then i would say no to backstage. When engineers get used to GUI they aren’t being engineers, they are just being tool users. Especially the folks new to IT world shouldn’t be working on GUI driven tools if they want to become engineers.
Almost everyone uses some UIs. I, for example, use vs code, grafana, k9s, and quite a few others. The question is not wether we use GUIs but rather for what. In my case, they are much better for observing something that performing actions or writing code.
@@DevOpsToolkit thanks for correcting my terminology. I modified my response. You are right. Correct word to use is “GUI”.
@@DevOpsToolkit Yes, for what we are using GUI is the key. I agree with you. For analytics and visualization, something like Grafana is good. But for writing code, it should be “writing code”, not clicking buttons and all that. Clicking buttons instead of writing code, doesn’t make us engineers.
In Backstage scenario, whatever it is doing, can be done easily with Taskfile & CI pipelines by doing some abstractions and letting the pipelines take care of storing the data into DB as well. This way Grafana can be used as UI for visualization purpose to see and navigate and click what’s required from Grafana itself, while the actual engineering work can be done by writing automation code in VSCode by leveraging Taskfile & some CI tool (like tekton or gitlab, etc.).
We already have a ton of tools to use, adding backstage to the list is just extra burden and more over just makes lives complex. When things can be done in a simple way, why make our lives complicated!!
@@DevOpsToolkit all the tools someone is building is to solve some problem, but they all come with one caveat, i.e., they are built as opinionated. Of course, there will be some opinions when developing a project. But in DevSecOps/platform engineering world, the core principles are common for any tools which fall under that categories. So, if everyone have one common way of developing tools into one framework, the world will be so easy, especially when dealing with knowledge sharing and handling securities.
I strongly believe and also demonstrated many times at the companies I worked for, the tools can be built simply by using a minimal utilities with the combination of CI pipelines without compromising security. Maybe i should do a framework and demonstrate in the public how that’s possible (if i find time, lol).
Anywho, my point is, CICD system is very powerful, a lot can be achieved just by leveraging that concept itself. Lot of folks think cicd is just automation pipelines, but it’s more than that. One can build tools/solutions when a right agnostic CICD tool is selected to use (something like tekton), to solve many problems, especially developers portal related category.
Backstage is a hub for all things dev. It is also extensible, with plugins contributed by various companies. The fact is that many companies do need this. The question is not why they need it, because they do, but rather why are they building it themselves.