This message was deleted.

Hey Dayuan! Driver inputs usually don’t belong in a Score file - they’re populated by the platform (according to the rules defined by the platform engineers) in the background, so the developers do not need to know about these things. There usually is only a very small subset of options worth configuring by devs, like t-shirt sizes or read-only options on data sources. It’s the platform engineers’ job to draw the line, what should and should not be at the fingertips of the devs - and also in a Score file. Cheers!

Thanks for your reply! All the developers need to do is specifying the resource type? Taking mysql as an example, what if developers want to config a feature only existing in AWS RDS Mysql?

Why would a developer want to configure it and what feature are we talking about? 🙂

Sorry, it is just a hypothesis and I don’t have a specific examples right now. What I am trying to figure out is whether developers only need to specify the resource type and another attributes like version, storage size, etc. are maintained by platform engineers.

Hypothetically speaking - yes, developers only need to specify the resource type almost every time. There are sensible exceptions to the rule, which must be determined and configured by the platform engineer according to the context of this company/platform. @Dayuan Li how would KusionStack handle the same situation?

In fact, we have been discussing this problem in our team recently. I will publish the initial draft of the design document to Kusion repo. Care to review together? 😀

Sure - if you post the link, I’ll have a look as time permits

Hey @Clemens Jütte, my name is Forest and I work with Dayuan on the KusionStack team. I used to run an Azure PaaS at Mastercard for a few years (I'm on the platform team) and I'm not sure I agree with this statement:

developers only need to specify the resource type almost every time

In my experience, app teams generally tend to want to be able to customize their experience on the cloud to some extent (still within the constraints of the organization, of course). The platform team can provide opinionated configs on certain things like Network ACLs, TLS versions, data encryption details, and such, because there is value in standardization, and it makes sense to have these things managed centrally. But it's hard for the platform to opinionate on things like what application db's replication strategy or failover strategy is, or how tagging and naming works, or things like postgres server parameters. If these are abstracted away from the app team, then you are homogenizing the requirements to build applications and that might introduce new problems.

application db's replication strategy or failover strategy is, or how tagging and naming works, or things like postgres server parameters.

As to whose responsibility that is, I believe it really depends on the organizational structure and that's really a question for the org. Some of these configs relates to the cost or the operational requirements for the application that the platform just won't be able (or it won't make sense) to answer or standardize, without knowing enough about the application itself. Or perhaps we don't converge on the terminology especially the scope of "platform team".

Hey Forest! You’re free to disagree - I am just illustrating my personal experience. I already put some concerns up, that usually are left for developers to control along with the disclaimer that a good platform will support the platform engineer in qualifying what is put forward for the developers to configure - and I stand by that, because in reality there are much less snowflakes than in theory! Regarding your last comment - the platform shouldn’t ever stand in the way of achieving outcomes for development teams. It shouldn’t be about power either. Platforming is never a 100% thing and needs controlled escape hatches for many reasons.

> a good platform will support the platform engineer in qualifying what is put forward for the developers to configure Totally agree with you on that. > in reality there are much less snowflakes than in theory Perhaps I'm coming from a different perspective but I've always been amazed by how many snowflaky requests that are coming from the application team for "business reasons". Probably a point of maturity in the software engineer org. Let's put a pin in that. > Developers can self-serve with no waiting times due to TicketOps, or the need to learn complex infrastructure. I'm trying to better understand this statement taken from here. Is the scope of self-service limited to what's in the developer's spec? Because if I'm a developer and I want to change something like my RDS instance class or if I want to add a new tag to my resource, am I supposed to wait for the platform team to do it? That's not really self-service is it? Are you saying that may not be a real requirement for the developers? I'm assuming the

score.yaml

looks like the one below (taken from the AWS reference architecture):

resources: 
  db:
    type: postgres

Again thanks for the time you put into responding. I hope these are healthy discussions to have.

Hey Forest! I suggest you spend a bit of time and read yourself into the Score specification (score.dev) and actually try it together with a platform - you could put it even in front of your own. Abstraction might be the name of the game, but the platform surfaces its capabilities through an interface - Score has all the means to accomplish what you want to do. If that is always ™️ the best thing to do - well, that’s a discussion we don’t need to have from my point of view as it depends on the context and choice of of the platform engineers. Cheers!