5 ms·
There has long been a set of tooling to make Infrastructure as code around how to interact with the Cloud Services or Deployed System , But the tooling around t
by vguptaDO 5y ago
There has long been a set of tooling to make Infrastructure as code around how to interact with the Cloud Services or Deployed System , But the tooling around that only failed us. I can give example Terraform State file with multiple developers (Its never agile when multiple developers waiting on each other to get a change updated) . Also more bad when the apply failed and no rollback can be planned as it's only one way change. Then with kubernetes we designed helm , applied changes are very config driven and God save you if you use conditional flow for multi-env deployments. More bad when you start to model the hooks in helm to provide some safety but you end up in a real bad state as helm failure update is not really runtime driven . Also we try to be smart on providing some values while deploying the resources but ideally they are never runtime so it just a pipeline effort to go and do something from vault somewhere but that vault is being updated by some external pipeline so we never have a real fix that is dynamic , ideally we need to be able to have a dynamic values driving the software in modern cloud driven world. we only need to be able to scale up / down the infra binary to use some of the tooling. Like for ex: scale (this is a binary) that accept some parameter like up / down and it is consumed by cloud resources. But idea is clear we need more dynamic software for developing, deploying, rollback, Run . @krisNova pen down the great idea , may we build on that to add missing pieces.
- streetcat1 5y agoI think that what you are asking is an undo in a distributed env. Which is not possible since the current tools does not support transactions. But this is true regardless if you do it declaratively (via yaml) or imperatively (via programming). In general, conditionals always exist, they just hidden in case of a yaml, or exposed in case of programming. I think that declarative way is better as it raises the level of abstraction (not unlike SQL).
- vguptaDO 5y agoYes so I think we need to have the tooling around 3 major Infrastructure development and overall developer experience on Infrastructure and Application Deployment. - Be able to Handle the conditional logic - Support the runtime to setup environment values. - Support runtime of any cloud service config in any cloud. - Interface for the Observability stack in the same runtime. - Rollback support for service and config. The benefit of all that would be to be able to Unit, Integration test of the code , Static Analysis , Security scan , Vulnerability scan etc , that way we have a "real" prarallel and dynamic turing complete code for infrastructure. Something around that experience is needed if we can get the community to support tooling around.
- streetcat1 5y agoSo, in a declarative system those things also exist, but they are written once (by the framework developer), instead of x1000 by each user. Its like a SQL join- I can declare a SQL join in SQL and let the RDBMS figure out the code(in which case I would need to verify the impl only once as part of the DBMS). Or I can offer NoSQL, and do a join in code by each user. I prefer to former. When you want everything as code, you basically LOWER the level of abstraction. All the tools that you mentioned, can also be run in a declarative system, but they need to run only once (by the framework/RDBMS) , instead of by users.