https://platformengineering.org logo
Join Slack
Powered by
I came here to say that we like to think that we k...
# general
j
I came here to say that we like to think that we know & control the path our developers are taking to build and deploy, but its not one-size-fits-all. We constrain teams at our own risk.
k
You're implying that anybody here thinks it is a good idea to restrict developers. That's an approach we tried in 2010 and it clearly didn't work. Platforms are like Siri or Amazon Alexa. If they work in 9/10 cases but fail you in 10% you still don't trust them. So yes, golden paths, not golden cages!
c
Super interesting one this. It‘s nuanced, it can be dangerous to assume “restriction“ is a dirty word here. In my experience the definition of restriction is very domain specific. Highly regulated industries are legally bound to restrict and this is where treating your platform-as-a-product becomes vital. Listen to all stakeholders, build in to your platform the restrictions you need, offer the flexabilities you need_._ Often restriction increases the closer one gets to production environments too for example. These can be examples of healthy restriction — these restriction ‘features‘ should be clearly communicated via your platform to your users so there is an understanding of why. On the other hand restriction for it‘s own sake is very bad (which I think is the intention of this thread and is how I interpret the response from @Kaspar). If developers are feeling restricted, then listen to them understand why they are feeling friction then offer the flexibility they need to be successful. The extreme opposite is a free for all which is unhealthy in whole different set of ways!!!
Ps. In past lives I have happily built many of the circa 2010 platforms @Kaspar is referring to 😆!!
k
Spot on, those of us who have done this for a while have all been burned by setting abstractions the wrong way.
I'm a big fan to not force restrictions on users but let them choose where they want to end up. And another key learning: you can abstract but NEVER at the expense of context. Let me give you an example: you have a system that matched an S3 bucket when you push to prod. Good abstraction design means you know exactly which bucket and how it was configured in detail. You don't need to necessarily be able to touch it but you need to understand it. Assuming you don't have a highly regulated environment you also want to understand how you can "leave the golden path" and customize the configuration of that bucket.
c
Raise a ticket and wait 3 weeks, right?
k
haha, correct.
j
And yet many developers complain that their platform team restricts their workflow. And so they go around them. And them people like me have to be called in because the unofficial work-around led to a security breach.
When it happens it happens because when is lack of communication between groups.
o
I think this "restriction view" is still the view of old platform team. For platform engineering, we build product. You can't restrict your customer but rather attract them. So instead of publishing rules, I believe we should provide them tools/APIs which make their life easier.
24 Views
Open in Slack
PreviousNext
Powered by