I disagree that internal platforms are a bad thing. Teams often benefit from consistently using the underlying platforms (e.g. AWS, Heroku) they are using. There are a million ways to Heroku, but likely you don't want all your engineers using a different one 1/ https://twitter.com/QuinnyPig/status/1327105051815333888

Heroku cannot enforce a naming convention, a way of managing config vars, the choice of or type of add-ons to use,etc. But your team may very well want to standardize those things. e.g. you may not see a reason to have MySQL and Postgres in production, at least by default. 2/

If your underlying platform is AWS, it's even more important to be consistent and intentional in how you use that platform. Are we tagging things? How do we use IAM? What regions are we in? Do we use terraform or cloud formation or click-in-console or what? 3/

Without standardization, rails, conventions, etc. this shit gets incredibly difficult to manage and navigate. It becomes a huge mess. I have been there with Heroku and have seen the seeds of this in AWS as well. It will not increase team velocity and create a lot of risk 4/

To deal with this, you establish conventions. You then need a way to make it easy for people to follow the conventions. If your answer is "documentation", I'm sorry, but that doesn't cut it. Even the most conscientious developers will only be able to follow/read so much. 5/

What you want is automation. Instead of documenting the CLI invocation to create your Postgres DB, you write a script that creates it in a way that follows conventions. That script has options commensurate with the conventions you've established and it evolves with the org 6/

At even moderate scale (say, 10 developers), these scripts can become a problem to maintain. Who owns them? How do we set them up? How do we manage all the API keys needed? How do we onboard new people? What happens if someone goes into AWS console anyway? 7/

So you put those scripts in a server and that server runs the scripts on behalf of developers who then no longer can directly access the underlying platform. Guess what? You have an internal platform. And this is FUCKING GOOD. 8/

When a dev needs a new database, they don't have to learn about RDS or whatever, they just say "give me database" and database appears, properly configured. If the definition of "properly" changes, it can be applied broadly to all databases. 9/

Of course, you need a team to own this, and that's your platform team. They maintain the internal platform that embodies the set of conventions and architecture decisions around how developers get their code into production etc. 10/

What you have to be careful of is allowing this platform team to dictate what those conventions are. They should have a big input into them—since they maintain the systems that embody them—but those conventions are team-wide 11/

But to come to the original point, I can't image a team whose default necessary surface area for running apps in production is "All of AWS" or even "All of Herkou". You WILL have conventions and standards and THOSE are conceptually an internal platform, and what I'm saying… 12/

…is that you do not want your internal platform to be an out-of-date wiki that no one can follow and isn't maintained. You want it to be code so your engineers can focus on business problems and not how to make sure they've set up replication on Postgres. /END