Hey Guys :wave: I'm part of a platform group which...
# platform-blueprints
d
Hey Guys 👋 I'm part of a platform group which is in discussions to try and draw the line between developer independence and developers shooting themselves in the foot, that way we can better decide how much control and freedom the developers get. You can say we are trying to position our internal services on a scale of PAAS to SAAS. We want super developers to find bugs in the internal services we publish, but 90% of our developers doesn't understand the infrastructure and are scared (skip) from complex logs. We don't want to make developers dumb regarding their infrastructure, but we want to really decrease developer cognitive load. We want to be enablers, but it will be easier for us to operate things like version upgrades for complex infrastructure our selves. Our internal services can vary in their complexity and their developer relevancy, from Kubernetes to AirFlow and many more. If anyone has an interesting take on the things I mentioned I will be happy to hear. If you can recommend articles or podcast episodes on this it would be great. Thanks! Posted in #general
k
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
d
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?
k
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 😅
d
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?
Thanks for your insights Kashmira
k
It does become a bottleneck at times, but when resources are critical, we need to make that tradeoff.
d
Ok thanks for your input
a
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.
FWIW Documentation is only part of eduction, its like publishing a text book and expecting people to understand advanced calculus. Thats the minimum required.
g
@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)