I disagree with the tweet by Charity, the end state can’t be internal APIs: Somebody will just build another layer over them to get IaC back for those APIs.
There’s no actual end state. It would be nice, however, if during the move forwards we would sometimes replace or even remove layers instead of just adding more.
I think Charity explains that providing teams with templates and modules of terraform/Cloudformation/Pulumi/… code is just a stop on the overall journey. She doesn’t seem to speak about GitOps as a concept or idea, but sharing bits of that IaC is just a hidden API.
Is that likely though? In a single internal organization I mean.
Perhaps you’re imagining these internal APIs to be exposing lots of fine grained control, such that they then need more code to glue them together to get something of value. I see them as encapsulating lots of complexity into higher level goals (e.g. new service with name X please). To hide the detailed complexity from teams who don’t want or have time to sweat the specifics.
I would think something’s wrong with how teams are communicating if then these consuming teams were glueing these APIs together with more IaC repos.
I agree about replacing or removing complexity going forwards. This is a hard and often painful process.
The thing with this is that it’s often fairly easy to make an API like this. We have one at work, you can get a service with all common features up in literally a matter of minutes.
The problem is that this is not maintainable: You now have state in some API, maybe somebody is configuring stuff in a UI, things will drift and eventually you’ll need to formalise your intent. Then the pendulum has swung back to IaC, and if you’re unlucky people will now build the IaC on top of the API mentioned above, instead of restructuring things to accommodate that correctly.
I wonder if what I’m proposing in this blog post is at odds with what you’re describing or not. Do you have feelings on how best to manage the ever growing surface area exposed by these IaC tools?
In the post I propose keeping things like IaC and CaC committed to Git. But to just put an API in front of Git to allow for cli or UI to be developed to speed up onboarding contributions to them.
I think that this is a sign that the feature flags are too long-lived. The configuration for a flag should live next to deployment-specific configuration (e.g. as an environment variable or element of argv) and should easily factor away to nothing once the feature is always enabled.
I disagree with the tweet by Charity, the end state can’t be internal APIs: Somebody will just build another layer over them to get IaC back for those APIs.
There’s no actual end state. It would be nice, however, if during the move forwards we would sometimes replace or even remove layers instead of just adding more.
I think Charity explains that providing teams with templates and modules of terraform/Cloudformation/Pulumi/… code is just a stop on the overall journey. She doesn’t seem to speak about GitOps as a concept or idea, but sharing bits of that IaC is just a hidden API.
Is that likely though? In a single internal organization I mean. Perhaps you’re imagining these internal APIs to be exposing lots of fine grained control, such that they then need more code to glue them together to get something of value. I see them as encapsulating lots of complexity into higher level goals (e.g. new service with name X please). To hide the detailed complexity from teams who don’t want or have time to sweat the specifics. I would think something’s wrong with how teams are communicating if then these consuming teams were glueing these APIs together with more IaC repos.
I agree about replacing or removing complexity going forwards. This is a hard and often painful process.
I wanted to add another point, but forgot:
The thing with this is that it’s often fairly easy to make an API like this. We have one at work, you can get a service with all common features up in literally a matter of minutes.
The problem is that this is not maintainable: You now have state in some API, maybe somebody is configuring stuff in a UI, things will drift and eventually you’ll need to formalise your intent. Then the pendulum has swung back to IaC, and if you’re unlucky people will now build the IaC on top of the API mentioned above, instead of restructuring things to accommodate that correctly.
I wonder if what I’m proposing in this blog post is at odds with what you’re describing or not. Do you have feelings on how best to manage the ever growing surface area exposed by these IaC tools?
In the post I propose keeping things like IaC and CaC committed to Git. But to just put an API in front of Git to allow for cli or UI to be developed to speed up onboarding contributions to them.
Oh yes, I’m dealing with this right now, and it’s not even one of the biggest organisations (5 digit number of developers).
That’s good to know! Appreciate the perspective. Sounds like a big org to me, but I’ve only worked for much (much) smaller orgs.
I think that this is a sign that the feature flags are too long-lived. The configuration for a flag should live next to deployment-specific configuration (e.g. as an environment variable or element of
argv) and should easily factor away to nothing once the feature is always enabled.