We probably agree that “you build it, you run it” is what makes for a good DevOps setup, correct? When we asked 1,856 engineering teams in a recent survey what their version of this paradigm looked like, it turned out that for 78.8 % “you build it, you run it” is more a dream than reality. What they are stuck with: their setup is too complex, their internal operations too immature to enable developers to self-serve end to end.

I’ve been constantly thinking about how to strike the balance between too much abstraction for developers and too much cognitive load. Should everybody have access to the AWS console? Should everybody be able to spin up any database? Or should we build a layer on top to be super strict but then restricting creativity? I wrote this long opinion piece showcasing some really negative examples of team setups I’ve recently come across.

My answer is: Golden Paths over Golden Cages. It depends from developer to developer how much cognitive load they feel comfortable with. So when you build your Internal Developer Platform you should never restrict developers from looking under the hood and even from circumventing the platform! Cloud-operations teams and developers should be in constant exchange about how to strike this balance, communication is absolutely vital.

To support teams on this journey we’re excited to announce general availability for Role-Based Access Control as the first of many governance features we will be adding to Humanitec. RBAC will now allow you to manage roles and access at an organization, application, and even environment level. Let’s go through a couple of cool governance use-cases I can think of from the top of my head:

• Junior developer Clark can deploy all the way to pre-prod. If something hits pre-prod, Humanitec’s webhook functionality will notify slack so delivery manager Mandy can confirm this deployment to production.
• Principal engineer Claude is a wizard when it comes to configuration files so he can alter baseline-YAML files low-level to add Datadog annotations across all workloads by default. Precilla is an external consultant at Nothinkingdoesntwork Inc. Claude doesn’t want to grant Precilla the right to change baseline config but rather enforce that the deployment manifests Precilla creates all follow the same rules.
• Security-Sebastian is super annoyed to have to check every single new database a developer spins up for security holes in the networking. So he configures a default driver and assigns it for use by a sub-group of developers. Now every time these developers spin up a Postgres for use in a specific application, the DB will be spun up in the security-vetted way Sebastian has configured. Developers don’t have to wait and Sebastian is freed from repetitive work.
• Audit-Audrey wants to understand exactly what was deployed where, when, by whom. Manager-Mandy simply pulls the deployment history and is done with the audit. She hates audits so this comes handy.

The above are just a few examples of what you can do to make your setup more secure, lower change-failure rates and reduce overhead and waiting times. And it works across all the tools you wire up to your Internal Developer Platforms. From the DB in your basement to any public cloud.

But remember: Golden Paths over Golden Cages - try to restrict developers as little as possible and never stop communicating.  

Neither will I.

Kaspar

‍