Question for you folks. Now that we can create com...
# atmos-dev
r
Question for you folks. Now that we can create components from upstream modules and even claude our own components, are ALL the cloudposse components still relevant and worth maintaining and creating new components? To push even further back, are there any modules that are so simple that aren't worth migrating to or using? If any are flagged, will those repos be archived or will their readmes eventually be updated to use the newer/modern approach?
I know this is slightly heresy here. Looking for an objective answer and realizing that i can also ask claude lol
e
To be clear, components are not to be confused with atmos; atmos exists as a product outside of our modules. I want to make this clear, because many people new to atmos think they have to use our components, our terraform, our modules. When instead, these are examples of how we use them.
👍 1
Since our components are part of our commercial refarch, they are not going away anytime soon 😃
We sell "quickstart" and "jumpstart" implementations which are turnkey based on these components 😃
but i think the future is companies will use components as boilerplate examples
and using claude/et al, manage custom iac at scale
Components ae still opinionated; opinions need to be held somewhere
Our modules are not that opinionated.
What I think is an antipattern, is when companies try to string together a bunch of modules in atmos stack config, rather than writing a component.
👍 1
p
I know you can claude your components away and use the very best for_each , and the supersuper new functions and all that but the interconnection between components is not that easy to get with one prompt. And at the end of the day AI needs and example to base itself from, therefore you need CP modules as an example. There is going to come a day where Atmos or another tool will just simple interact with the AWS MCP already allowed in your account with certain identity centre role/oidc and you will be able to just instantiate the resource in the stack and it will just interact directly with the API without needed TF anymore. That day is coming, I'm just planning to be retired by then.
😃 1
e
z
Speaking on this. We have a bunch of components that rely on eachother, say for a specific application. We use workflows to deploy them, in order. Is that in line with how the tool should be used? ( we dont have space lift or any "nice QOL" tooling)
Atmos is our nice QOL tool lol
e
😃
Yes, although we have plans for an improvement to that
cc @shirkevich 😃