Hi all… We are currently discussing two approaches for building our dev platform 1. abstract cloud completely from dev teams - for databases (PostgreSQL) for example, the dev team would just get connection string, and they are good to go 2. abstract cloud but build reusable artifacts - for databases, that would be terraform module for example. But then the dev team is responsible for using it. Option 1 is appealing because it is 100% hands-off for the dev team, but the concern is that as we keep adding services to the platform, the Platform team will become a bottleneck, and they will be dragged into team-related operations. Option 2 is appealing because the same best practices are encapsulated within reusable artifacts, but responsibility and work load is shared between the Platform and Dev teams. The concern here is that it is unnecessary complexity For context - This is for the mid-enterprise company with ~30 scrum teams and one Platform team of 10-15 engineers. I would love to hear other people’s opinions.

We are fairly small compared to you ( only 3 teams ), but we went with option 2 to allow the teams to contribute if they want/need to so that ops does not become the bottle neck in the future if we scale up quickly

Deal with your services as products, you own them end to end. From a dev perspective; if I want a database, I would like to be able to create a DB instance on demand, being able to monitor it. I don’t want to maintain it, back it up, scale it up or down. Cloud providers already provides all these features, you just need a simple wrapper that’s accustomed to your special needs

Hey borkke! I am probably not clearly understanding your distinction between the two options, so I'm giving this a shot - please consume with a pinch of salt. When you add a service to your platform, one of the main goals (as I understand platforms) is to add automation and self-service. That leads to the fact that "adding a service" does not equal "creating a database and sharing the connection string" - good old ticket drive processes from pre-platform times. So the bottleneck in both cases must be "creation of a service for the platform", as the "requesting a service instance" in both cases "your own interface" or Terraform is basically the same effort for the developers with the difference being in the interface. When it comes to the creation of services, I would not let developers do that. The main reason being, that developers should not delve into the depths of the internal alignment needed to create a service (e.g. security, compliance, legal, contractual, etc.) and also should not make decisions on the defaults that come with a service, as their perception of sensible defaults is just more limited than what the platform team can observe across all teams. Please let me know if my understanding of what you meant is wrong - I'll be happy to re-think!

“When it comes to the creation of services, I would not let developers do that” - by this do you mean a) they should not stitch together individual (azure) terraform resources that makeup “production grade” database (by them selfs) or b) they should not use the pre-build TF module (provided by the platform team) which abstracts small bits and pieces that makeup “production grade” database?

They should not do "a", while doing "b" is totally okay if that is the "API" of your platform. The reason behind that is, that "a" does not include the abstraction about what "production grade" means - this should be the expertise that the platform team adds and the platform itself encapsulates and automates. Does that make sense?

Yes, sound alright

I would vote for option 2. Too much abstraction often leads to engineers not understanding the "magic" under the hood when they need to deal with it, like during a production incident. It's better to expose them to some details with reasonable defaults so they normally don't have to care until they get to production and need it. The other point for 2 echos @Hugo Pinheiro’s comment that it would allow teams to contribute and adjust the modules to fit their needs. Your platform team will never be able to accomodate every use case and it's better to build abstractions that are customizable by the product teams that know their own needs better.