This message was deleted.

I will respond in the AWS context - but should be applicable to other providers. I would say developers should never have to (be allowed to) do anything that changes core infrastructure. They may have the tools to stand up resources they use for their applications, such as S3 buckets or SQS queues, etc. Platform can offer to manage “mission critical” resources for them - such that developers create the pull requests to manage these resources, but it goes through rigorous review by platform team, and only platform can merge and deploy. Things that are not mission critical can be managed by teams themselves. Platform can provide guidelines, but up to dev teams to decide whether they want to manage their own resources, or give guardianship to platform

What are your criteria for a "mission critical" resource? What do you mean when you say developers can choose to manage their own (non mission critical) resources? Do you mean override default settings set by the platform? or is there a different "mode" the platform team created for super-developers?

Mission critical would be something like any long lived resources, resources that are critical to the operation of the services. We can’t have a junior engineer accidentally delete or edit these resources. These things fall under the guardianship of platform. When I say management of resources - I mean anything from creating, editing and deleting resources. We have all operations for resource management done via terraform. So the code for resources under platform guardianship resides in platform owned repos. Code for dev team managed resources lives in their own repos. Hope this is helpful. I’m wondering at this point if you and I are talking about different things 😅

We have a “metadata” directory on every service repo, owned by the developers who own that service. They can host their service on their own K8S cluster, owned by them, using terraform modules we write and they consume. Don’t you feel like a bottleneck for infrastructure when you need to approve infra changes?

It does become a bottleneck at times, but when resources are critical, we need to make that tradeoff.

Ok thanks for your input

You probably need to have a three prong strategy: 1) Technical 2) Education 3) Process. Its easy to do what you love which typically falls into the technical. #2 is highly underrated and requires real work. If your organization is serious about the long term platformization impact then almost every project — both in product and in platform — needs to budget the time to do work in all three categories. You may choose to trade one off for short term business impact but you should look at 3-6m horizons where you’re investing.

@Dolev Algam very interesting scenario, it is great you are discussing what sounds to me like inner sourcing. ie: continuous improvement of services with input from the super developers. 🙂 Perhaps your org may benefit from investment of time/effort on a platform portfolio strategy. At high level, It should include things such as: the strategy to catalogue/define the internal services so as a developer not only i can get the infra, but the service is defined/made available in a way that is known to comply to internal req AND meet developers req. Some analysis of current portfolio would prob be beneficial too to identify potential gaps on existing offers, ie: is there a pattern, with some services being highly modified? should there be a specific set/approach to complex infra, so developers using those can be given as much autonomy as possible?- How would that look like? Overall, answers to those would help, i would strongly recommend tackling from a a technical and non- technical perspective (so the overall strategy and model for platform as product)