Hey there,
Across dozens of conversations in the last few months, one thing is becoming clear… a good number of portal implementations fail. And I don’t really think we all totally get what the reason is. Because it’s less about the portal and it’s more about the way teams architect their platform (hint: the wrong way). But let’s start at the beginning.
Platform architecture can be similarly thought of as service-oriented architecture. You have components of a platform, you have communication protocols between the components. You usually have a frontend(s) for presentation and a backend(s) for logic handling.
Now in certain cases you might want to put logic into the frontend and execute it “client side”. That is usually done in logically clearly differentiated requests that require limited logic handling. This could be a single request based on prior filtering for instance.
Once it comes to more complex logic or sequenced requests that require pulling data from several sources and acting on it, it’s good practice to put this into a dedicated service and design the logic in an efficient, testable way.
The same holds true for platform architecture. If you have a small scale platform for 50 developers it likely doesn’t matter how you design it. Stuffing things into a frontend layer like Backstage or JSON files that turn into frontend modules or in the worst case “drag and drop” logic is totally fine. The same holds true for “simple requests” such as “add a new Github user” or “execute this template by calling the Github template API”.
The problem is: it sounds nice, but doesn’t scale. If you have your entire platform logic in your frontend you have a (really bad) problem…
A.) requests that you can call from a frontend without additional business logic are calls you can likely do without a platform - the added value is low.
B.) logic in the frontend is impossible to maintain and keep up to date. Your usage will be disastrous.
Good platforms should be capable of executing on requests such as “I am a developer, I want a new S3 bucket for my workload”. And after this request I don’t only want this resource by executing a TF file. No, what I actually want is WAY more complex: I want to have a matching for exactly what configs my org wants me to use by environment. I want those resources created, I want the workload configs to be updated, I then want the credentials injected through secrets at run-time, and everything served. And if the definition of any of those resources change, I want all resources that are running that consume this, to change too.
This level of sophistication is what brings real value in platform engineering. Executing and even configuring this in a frontend is impossible. Which is why good platforms have frontends (Score, Portals, CLIs) and backends (Platform Orchestrators).
So what does this have to do with failed portal implementations? Well just that. If you abuse something like Backstage for anything else but a presentation layer you will fail.
Good luck out there :)
P.S. attending KubeCon Paris next week? Come say hi (or argue with me) at booth #D35!
Kaspar
