j

Joshua Gilman

09/21/2023, 12:10 AM
What are the options for a small (~2 engineers) team exploring platform engineering that will enable quickly bringing up an IDP? We are going back and forth between leveraging existing products and establishing "golden paths" via low-level automation. Our primary concerns with IDPs are: 1. Scope creep. We are trying to generate value, not make the next Titanic. 2. Inflexibility. We want to establish a fast feedback loop and don't want to fight with constraints that force us to compromise too often. 3. Cost. If the cost of the IDP exceeds the value created, we've failed. Any tips or feedback?
p

Pradeek J

09/21/2023, 1:15 AM
Most important thing is to make sure there are at-least a handful of clear pain points that are impacting the business that your team can actually completely solve for. If you are looking at golden paths for example, how often are you shipping new services, what does further automation here actually save? If its saving time for devops team but the actual devops team does not have anything higher value to do, this might not even be necessary. Likewise, can the problem at hand be solved with a template repo + ci automation + documentation. Maybe a brute force low-tech approach to solve the problem first can create clarity on whether an IDP is even required.
a

Abby Bangser

09/21/2023, 9:54 AM
Another thing is suggest is making sure to decouple implementation from interface. What you need today will likely change. So keeping your cost of initial implementation low matters, but keeping your cost of change low is even more important.
n

Nathan Hruby

09/21/2023, 4:58 PM
For two people? • Process docs for others to follow (eg: instead of automating a flow, write it down in an easy to follow list) • Templating configs to automate initial setup and make it easy • Build tools that give people extra powers/access instead of giving people the access directly (eg, a lambda that can run a deploy, then people only need access to run that lambda)
code is expensive, docs are much cheaper, so start by writing things down adn having people follow it. For small teams, this works remarkably well and is easily updatable. Then start adding some light, reusable automation around the time consuming, tricky, or privileged bits. After about a quarter you should have a good feeling about where you should invest more (proliferation tools, sustaining engineering efforts, governance, etc..)
j

Joshua Gilman

09/21/2023, 5:06 PM
Solid feedback. Thank you, everyone 🙂