Hello team, I'm currently evaluating a solution to platformize the infrastructure provisioning and management at my organization. I'm a platform noob and have a series of questions around what's the IDP value prop? How does gitops fit as interface for an MVP infra provisioning platform? and several other aspects. Would appreciate if anyone would be willing to have a quick chat to clarify some of the aspects... Thanks in advance!

Hey Vikas! GitOps is probably not the interface you’re looking for. Let’s assume that you want to use IaC because you’re provisioning infra. You want to have GitOps as a means to have all changes documented and a clear workflow on how to submit and review changes. One part of the interface would be the IaC language. Then you would need more tooling because having the changes in Git will not execute them against a targeted system and there is no progression for environments with Git alone. The interface of that tooling would form the second part of your interface as it provides the user experience and workflows beyond the IaC. It’s safe to say that when you have solved that riddle (let’s assume again you’re using Terraform because it’s the most used IaC out there, by having something like Atlantis in place) you will be off to the next challenge: how to forward your infra config to the applications using that infra to bake working deployments (most probably the outcome you’re looking for). A platform orchestrator is a platform component that solves all those issues for you. This community is curating a tooling landscape to give you an idea of platform components and how they align to become a complete platform. If you have specific questions, LMK. If you want to drink a virtual coffee together, feel free to DM me.

Thanks a lot @Clemens Jütte! Yes, on a core - something I had in mind so far is on the likes of: 1. Version controlled IaC Modules and configs on a git repo 2. Some TACOS like Atlantis or likes integrated to CI/CD tool to get real world infra or any gitops operator 3. Lastly - yea integrating that infra config like connection string or some hostname or likes to the deployment so the service can use it. This is the value prop I've in mind and you've seconded that it's something orgs likely wish to achieve. Would it be right to assume that GitOps would only take me as far as 2? Some more questions I've is: • How does a Developer portal help here; get from 2 to 3? Or can github (UI) + terraform + ci/cd + platform orchestrator suffice a MVP IDP? • With the self-service nature of IDP in infra provisioning - would developers have control to provision production resources? If not what's the self-service value-prop being spoken about?

The IaC Modules / blueprints complement the platform but are not themselves the solution?

IMO this is the key change in perspective as we move from devops to platform engineering. IaC is an implementation detail and people who are writing it should also be running the infra it creates. Else you end up in a world of decay with maintenance issues on who updates the templates, who runs the updates, who manages or is on-call for the resulting infra. which leads to your question:

• With the self-service nature of IDP in infra provisioning - would developers have control to provision production resources? If not what’s the self-service value-prop being spoken about?

This is something that only you can decide, but Bryan Oliver described handing IaC templates to app devs as giving them a puppy for Christmas. That is a great present, if the recipient understands the expectations and can fulfil the requirements in the long term. Else, you may need to provide something more supported. The decision here is basically the same as a cloud provider responsibility matrix. Deciding who has responsibility for what and how they are given the tools (observability, access, training, etc) to manage those responsibilities. So if your mentioned goal is self-service, IMHO your next step is to figure out what the contract of that self-service looks like. What can people request, what details do they need back from that request, how will that request be managed over time, etc. If you plan to hand implementations (IaC) out to app teams, you are most likely thinking about scaled DevOps structure where you need to focus on code packaging/sharing/updating. And if you want to hand out services they can depend on (e.g. we depend on EC2 instances that AWS provide to us as infra engineers), then you are most likely shifting to a platform mindset where you need to focus on that contract / support model to make sure you have trusted and useful services for them to depend on.

The second view is much better from my perspective as it focuses outcomes and not their technical implementation. From an orgs perspective however, the underlying IaC is nothing that belongs into the hands of singular developers / teams. The reason is that this is the opposite of standardization. Platforms are meant to abstract complexity in usage for developers and also complexity in maintenance for infra & operations. Without stadardization you will not get to fleet management - which is one of the main perks of centrally operated, commodity infra with self-serve by a platform. Where those journeys of your platform users start and end - how much self-serve is possible without any interruption, like sign-off or ticket workflows, is yours to determine. I am opinionated there - strive for a 100% 😉

Thanks Abby and jay. Refining my view again: 1. As a platform engineer, I integrate the components on the original post (Orchestrator + CI/CD (with Infra Control Plane) + Policy Engine) 2. Either my team or someone, like say a Infra team, standardizes the infra via IaC modules/blueprints 3. Developers just focus on consuming it in a easy way with minimal to no interrupts Git can be the backend for source of truth but developers shouldn't have to likely use it as an interface and worry about the intricacies or specifics of the IaC specific language/syntax. P.S. - I agree, standardisation & better governance is def a goal but yea it's kind of on the dark side for devs (appealing to me; seems like loss of flexibility to them simple smile) Am I taking the right pointers back home?

IMO very nice summery!

Great summary! I wouldn’t be too concerned about devs losing flexibility. There are not so many things where devs are not readily onboard to trade a minimum amount of flexibility against the fact that they auto-pass the next security audit, don’t need to care for backups and the like, or carry a pager and be on-call anymore. If you don’t take away context so they can observe what the platform is doing in the phase where they need to gain confidence in it, they will settle back into the comfy part of the abstraction quite easily. Bonus points if you have a participation model where devs can help shape the future of the platform with their requirements or even with contributions in the form of pull requests.

Thanks a lot guys! Appreciate helping me shape my understanding from 0 to 1...

just catching up on threads here : how this going? NB i notice many other things missing from that platform tools image.. I'm an SA here at GitLab and doing loads of work on GitOps standards and industry 🙂

@James Moverley this is community driven. If you feel there is something significant missing, then feel free to submit entries. 🙂

100% 😄