This message was deleted.

I manage a Platform engineering team, BTW, which is why I’m thinking about it.

A lot of it depends on how you think the strategy for your platform and the pain points. Happy to chat through with you if you’re ever interested.

don’t stick with backstage discovery tool, you can have a separate repository to manage entity structure in backstage. start with it https://backstage.io/docs/features/software-catalog/system-model it will help to understand what entities and their relations you can use. https://backstage.io/docs/features/software-catalog/configuration use location type: url to point backstage to entities source you don’t need to stick with the monorepo

I agree that backstage is more of a solution for microservices. You may find as your organization expands it may be more useful at that time, but not all problems can be solved with Backstage. Similarly a monolith could be a really good pattern with a small team.

You probably get a bigger impact working on the paved road for production (CD system etc) than focusing on developer platform with a monolith. The other place I’d look into is your testing strategy for monolith and how you want to create library interfaces. You need to decide on the long term technical strategy first then work backwards to the technology.

platform doesn’t connect with monolith or microservices, platform (specially backstage) operates with system components of different types. It doesn’t matter what “State of matter” your application has. Because good monolith it’s set of services (SoA). you may have monolith as monorepo and external system model described in backstage components in a separate repo.

That all makes sense. Thanks for helping me chew it over, everyone!

@Andrew Fong please could you elaborate further on the paved road and testing strategy portion of your message? We're in a similar space, albeit slightly ahead. We've just completed decoupling a monolithic application into a (mostly) API with a bunch of micro-frontends all being stitched together by NGINX. We're at a point where testing features across these distributed applications is becoming a burden for developers - they have to stitch everything together and partial review apps are just not cutting it. Our CI is pretty sturdy and we're working on our testing strategy. We've toyed with the idea of using backstage to venture into IDPs, with the above requirement (Stitching together different versions of distributed applications) as our minimum viable feature set. Do you have any thoughts on this?

Not sure how backstage helps here, the problem is the versioning of APIs against features right? built feature on v1 of service X, service X got bumped to v2 along the way? need to constantly build and test everything in all variants to ensure rollouts are safe?

@Kyle Gani for me it sounds like a new monolith. MFA should be run in isolated environment with minimum dependencies as possible. MFA is the same paradigm as MicroServices, but for frontend. If it depends on each other - it’s a result of bad architecture. Try to decouple it (https://home.adelphi.edu/sbloch/class/adages/coupling_cohesion.html) in most complex cases, API provider team has to follow backward compatibility of API as much as possible, it will slow down development speed but it will increase stability.

getting to a common protocol and serialization format is key - types are a must. JSON/REST is awful and just leads to headaches later

I partially agree with Andrew. scalar types isn’t so important but nice to have (maybe my experience of languages without strict types is speaking), consistent data structures are a must. JSON/REST - is good only for CRUD operations, but REST doesn’t describe other operations, triggers, events… everything what we are calling a business logic of an application.

haha @Andrey Korolyov you and I both on the languages w/o strict types 😉 YouTube/Dropbox are all python. managed guido and the mypy team at one point trying to solve the headaches of 4M-6M lines of python