| Nope - I mean we make a 1:1 model of the real resource, and then let you propose changes to that data model. Rather than thinking of it like code in a file, think of it like having a live database that does bi-directional sync. The speedup in validating the change happens because we can run it on the data model, rather than on 'real' infrastructure. Then we track the changes you make to that hypothetical model, and when you like it, apply the specific actions needed to make the real infrastructure conform. All the policy checking, pipeline processing, state file management, etc. is all streamlined. |
| |
| ▲ | holoway a day ago | parent [-] | | For what it's worth, that means hitting the 'apply' button in System Initiative. It's a totally viable workflow - it's not either or, it's 'and'. | | |
| ▲ | AOE9 a day ago | parent [-] | | Yes hitting apply would update the production infrastructure, but what if I want to run automated testing to check a change/new feature? I can't do that on a simulation. | | |
| ▲ | holoway a day ago | parent [-] | | Right - obviously, if you need the actual code deployed to run your test, there is not much anyone can do about that. But let me tell you how you would set that up, from scratch, in System Initiative (assuming you have a working deployment at all). I assume the use case here is 'I want to deploy the application on every pull request to net-new infrastructure, then run my test suite, and destroy the test infrastructure once the PR is merged or the code is updated'. You would fire up the AI Agent and ask it to discover an existing deployment of the application. Probably give it a hint or the boundaries you care about (stop at the network layer, for example - you probably don't want to deploy a net new VPC, subnets, or internet gateways). Once that's done, you'll have a model of the infrastructure for your application in System Initiative. Then you'll turn that into a repeatable template component, by either asking the AI to do it for you, or selecting the related infrastructure in our Web UI and hitting 'T'. You'll add some attributes like 'version' to the template, and plumb them through to right spot in the code we generate for you. Then you're going to call that code from our GitHub action on every PR, setting the name and the version number from the branch and the artifact version, naming the change set after the PR as well. You'll let the action apply the change set itself, which will then create the infrastructure. The next step will be to run your tests against the infrastructure. On merge you'll have another GitHub action that opens a change set and deletes the infrastructure you just created, so you don't waste any cash. Notice what I didn't tell you to do - figure out how to create new state files, build new CI/CD pipelines, or anything else. Just started from the actual truth of what you already have, used our digital twins to make a repeatable template out of it, then told the platform to do it over and over again with an external API. Hope that helps it make sense. |
|
|
|
| |
| ▲ | holoway a day ago | parent [-] | | Nope. Terraform/OpenTofu state has several big differences. The first is that Terraform/Tofu can drift. This is why people suffer when a change gets made outside of IaC, and the statefile no longer tracks. That's because IaC tools are by design unidirectional - change should only ever flow from the IaC to the Infrastructure. In SI, this is fine - the resource state can update, and then you can decide if it was beneficial (at which point we just update the component side of the equation, and you're done) or not (at which point you would decide what action to take to revert the change.) The second is how it gets generated. In Terraform/Tofu, it's a side effect of the 'apply' phase - basically a compile time artifact. In System Initiative it's the heart of the system - the code you write is operating on that model, not generating that model. This makes programming it much simpler. You can change the model through our Web UI, you can change it through an API, you can change it with an AI Agent, the resource can change because the underlying cloud provider changes it, and it all just works. | | |
| ▲ | stackskipton a day ago | parent [-] | | State can drift in SI as well unless you are subscribing to events from AWS that alert your system as soon as resource is changed so you can update your side. >the code you write is operating on that model, not generating that model. What are you talking about? That model is not reality because reality is whatever the state of resource is in AWS. If your model says my S3 bucket is not public but someone changes it in AWS to make it public, who cares, it's public and that's what's important. Sure, your system may update itself more frequently than only when I run "tofu plan/apply" but at end of the day, it doesn't matter. All I'm saying as SRE, you have done poor job selling this to me. I'm telling you what I would tell my boss if he came to me with this product. "This is some custom IaC system with AI Agents sprinkled on top. I guess if you want to get rid of SRE team and replace us with their consultants, whatever, I won't be here to care. If you want us as SRE team to use it, nope, it's a waste of money since OpenToFu has much better support. Can you approve my SpaceLift purchase instead?" | | |
| ▲ | ryanryke a day ago | parent [-] | | > Sure, your system may update itself more frequently than only when I run "tofu plan/apply" but at end of the day, it doesn't matter. Correct me if I'm wrong here. In my experience you have to "apply" before state is updated. This would mean we weren't quite operating on the source of truth. (aws in this case). 100% it's a solvable problem with a TF centric tool chain. But it's still a problem that needs solving. In my experience with SI it fades to the background. Now, I'm sure there is an edge case where someone edits something outside of SI while I'm trying to simultaneously update it in SI where things might break. I haven't run into it yet. > All I'm saying as SRE, you have done poor job selling this to me Can't argue this, but I would say like any other new tool, it's worth checking out. :) | | |
| ▲ | stackskipton 20 hours ago | parent [-] | | Yes, at apply stage, the state is updated. All the state is useful for is finding the resource for big 3. In fact, I'd argue for TF, they could do away with state file beyond
resource "s3_bucket" "thebucket" -> arn:aws:s3:us-east-2:000:0123455 since they pull down the current state of system as is and then show you the "This is what you want and with current state, this is what it will change." > I would say like any other new tool, it's worth checking out. :) I don't see the need for a couple of reasons: 1) How? If you want me to try something, either big "TRY ME" unless it involves becoming a client which that case, I see you as replacing me so my motivation is zero. :D 2) I'm on Azure for most part so it's useless anyways. 3) You have not shown me how SI is that much better than Terraform. If I'm going to invest time over yelling at Kubernetes, I need to know my time is worth it. At the end of the day, we all want the same. Here is defined infrastructure, be it YAML, JSON, HCL, some GUI, API call to a system, Whatever AI is smoking. Ability to see what changes and make those changes. HCL/ToFu is what most of have picked because it's pretty open and widely supported across all the providers. You have to overcome all that. This blog post reads, we have this great new Windows Server thing that will blow your Linux Server stuff away completely with GUI and Siri. Maybe that's what your customer base needs. However, at technology companies I work at, we don't need that. People editing outside IaC is done very slowly, deliberately and almost always backported. If not, you will get called out. It would like Dev writing code and no tests. | | |
| ▲ | ryanryke 8 hours ago | parent [-] | | Thanks for responding. I love these conversations. >1) How? If you want me to try something, either big "TRY ME" unless it involves becoming a client which that case, I see you as replacing me so my motivation is zero. :D To be clear, I don't see this as having the capability to replace engineers. This is a new way to interact with your infrastructure. But it also feeds into larger AI conversations as well. (probably out of scope for this conversation :) ) > This blog post reads, we have this great new Windows Server thing that will blow your Linux Server stuff away completely with GUI and Siri. Now you crossed a line :D Jokes aside, there is a HUGE community in the TF and now OT space, you can't argue that. The ecosystem of third-party tools to help support workflows is gigantic. Putting all of that aside, will that be the best way forever? I'm not saying that SI will replace either one of those, but I would say it's a new and refreshing way to tackle a similar problem space. >2) I'm on Azure
Sorry ;-P |
|
|
|
|
|
