Hey folks, an interesting discussion going on internally and I was looking to hear the community’s opinion on this We’re “building a platform” by standardizing on top of crossplane, the issue came up when one of the guys was tasked with delivering S3 as a platform offering (catalog item) Argument 1: We should expose everything the S3 API has to offer since we can’t anticipate all user needs The counter to that is that we’ll be providing support for configuration, and that’s not the platform approach Argument 2: We should provide an abstraction that is S3 The counter to that is that we’ll be playing catch-up every time a new demand comes in and users will bypass the platform whenever it doesn’t serve their needs. You can imagine the debate has much more details and counters to it, but I’ve brought the gist of it here to see 1. how much of an issue is this? are people facing this dilemma often? 2. what’s the more common approach? I don’t think there’s a right or wrong it’s a matter of what fits, but still if there are any stories around this I’d love to hear 3. just opinions in general if there are any

IMO it's better to not restrict devs and instead give them an escape hatch, because as mentioned its hard to anticipate all of the needs as your team. If there is a particular standard setup you would like to see happen as the common case then simply invest the most time in making that path the easiest and developers will naturally gravitate towards it. This has worked pretty well for my platform team.

What Andrew is saying is 100% right. Your goal is to make life easier for as many developers as possible (by creating a golden path) without making the rest miserable (by allowing them to go off the path, of course knowing the “consequences”).

IME, the perception that option 1 means no maintenance is a false hope. AWS (or any cloud provider) will also update it's API, there will always be new offerings. There will always be changes. So I definitely agree the goal is to pave/gold paint the sensible defaults and then expose override options. To extend further though, IMO you should either give the devs AWS, or build a platform, but not create just an in house pass through to AWS. IME when you create a pass through when things go wrong, there is a hard to debate battle of if it's AWS or your platform. The platform team ends up saying "but it's just AWS!" and the app team says "but I'm asking via your platform!". Both are right but neither is helpful 😅 If you go platform, IMO your interface should be customer (app team) informed and usable, and your features/offerings should include the codification of any business requirements.

Argument 2.5? Sorry - I'm not slack savvy and I've been trying to figure out the @#$%^ linebreak (shift+enter) 🙂

Haha, maybe best summed up as argument 2 with some indication of implementation preferences? 😅

So "s3" is amazing, and broad. So broad that we have several different components that are "backed" by S3, but offer quite different configuration options, defaults, and capabilities.

Static website vs public bucket vs private bucket are three very obvious ones I have used before

Then the other question is "if someone wants a new flavor of "s3", how fast & easy is it to create/test/document that and get a new componnent they can test for their use case

And that is where you may have 4 options, “static website”, “private”, “public”, “custom” and allow the custom to be the escape hatch. Then the goal of the platform team is to figure out. how to migrate away from custom to either an existing option or a fourth common pattern as soon as it is reasonable.

I’ll share what we ended up with after a few days of talking - I hope I can convey the logic over slack. 1. Some AWS services must be provided as CRDs (items) in the platform (like EKS or RDS) 2. Others, (like S3 or KMS) - the argument was that even if using terraform we wouldn’t provide them as a separate module - the idea of a “hybrid approach” was raised 3. Eventually, we decided to survey all DevOps teams for a list of AWS services in use, we’ll deduct the ones we agree to provide as an item 4. What’s left we’ll go one by one and scope the usage of it to provide it as an item anyway

Cover 80% with the golden path, then for everything outside, let teams use the same tools that you use for your platform. It should be with the understanding that they have to learn and support that. Once that unique usecase becomes common you can bring it into the platform. I feel though stepping outside the platform should be with good reasons and not just because someone is more familiar or cant figure out a way to do it with the current platform. Just like your company’s main business may not be unique infra, each team’s mandate should also not be unique infra. We had team want to do serverless because they had it part of their design. They ended up spending a good part of 6 months learning/implementing that which already existed in our k8s platform and there was no other team to share the burden with. Now 1.5yrs later we have several teams using serverless framework and standardizing the workflow that we have enough usage and teams to standardize and make it a golden path.