This message was deleted.

I have definitely felt that pain. At one of my previous companies I was lucky enough to only have 25 repos that the platform team needed to update to move from a self hosted Kubernetes to AWS EKS facepalm One thing I noticed in your design is that you put “Internal Developer Platform Interface - UI” as your intermediary layer. A pattern I am seeing is that people are getting really excited about user interfaces for the platform. But building logic into the GUI can just tie us to another hard to change abstraction. What happens when someone needs to use the platform as a part of CI/CD? Likely a CLI would be a better interface. So not sure if I am reading too far into your UI statement there, but it is something to maybe keep in mind 🤷 If this resonates, there was actually a talk on this at Platform Con by a colleague of mine: https://platformcon.com/talks/backstage-does-not-an-internal-platform-make

wow thank you for sharing such a good resource I’ll have a look at the video!

@ahn heesuk Can you please assist me by providing an example that illustrates this pain point? I would like to understand the problem statement and the specific solutions you are seeking. We can consider using either "Backstage" or "Port," or any other IDP, to address this issue. Our primary focus should be on developing abstractions rather than creating illusions within these IDPs. Based on my understanding of your question, we have employed the "Software Catalog" feature of backstage. This feature triggers our onboarding pipeline, which, in turn, generates repositories with initial code and adheres to organizational standards and best practices. It also establishes CI/CD pipelines linked to these repositories. As a result, the team can proceed with coding, and the code will be automatically built and deployed, significantly reducing time to market. Additionally, our team is consistently releasing new features. To facilitate code modifications and automate the migration process, we employ tools such as "git-xargs" and "projen." These tools help generate modified code and raise pull requests (PRs) for all the repositories that require changes. However, I am open to hearing alternative approaches if anyone has a better way of handling these situations.

@Anshul Garg The problem our team was experiencing seems to be a problem caused by not providing the platform as a service but as an infrastructure. For example, let’s say our team built a monitoring tool consisting of a set of Grafana and Prometheus. One day, an inquiry comes from another team. “Hey, can our team also create and use a dashboard for Grafana that your team created?” Then we reply, “Of course!” The problem is that this is the beginning of a tragedy. Gradually, other teams start using what we built, and after a few years, it becomes a huge legacy monolithic service. We find it difficult to run this legacy and start asking other teams to do it. “We’re going to take this service down and migrate it to a new service. Can you separate them now?” “Oh, but I’m busy right now... I’ll take care of it later.” Taking down the legacy components used by all teams like this requires a lot of communication cost and effort. Contrary to our team’s original role, before we know it, we start to become “notification bots.” This is a problem our team faces, and in order to get out of it, the platform should be provided as a product service to provide abstraction, and the backend should be able to improve only under the responsibility of our team.

@ahn heesuk We had a similar problem, and we found a solution that is currently working well. We used a strategy called Monitoring as Code (MAC). Our SRE/Platform team created modules that create dashboards, alerts, and other things in different monitoring tools. All the complex automation code for these modules is stored in a separate code repository managed by the platform team. The application team only needs to include a small piece of code in their own repository that calls the main Terraform module and provides some application-specific variables. The CI/CD process takes care of the rest. This setup allows us to add multiple features to the core modules without breaking changes. When a new release of the core modules is made, the application team's CI/CD pipeline automatically picks it up without needing to modify their code. If the application team no longer wants to use a certain dashboard, they can simply remove the small code snippet from their code, and the pipeline will handle it. We relied heavily on Terraform to achieve these capabilities.