5 ms·

Hey - CEO here. Happy to answer questions if y'all have any.

VectorLock 3y ago
Was this something you had planned to announce prior to the whole Terraform kerfuffle and it is just unfortunate timing, or was this precipitated by that event in any way?
- holoway 3y ago
  We've been planning to open source it this way for the better part of a year. It just so happened that we were ready to open it up right after the Hashicorp folks made their decision. No intentional timing. You can see more on our approach here: https://www.systeminit.com/open-source/ https://www.systeminit.com/open-source/
mdaniel 3y ago
Apologies if this comes across as "gift horse mouth"-y but https://github.com/systeminit/si#local-development-setup https://github.com/systeminit/si#local-development-setup and its https://github.com/systeminit/si/blob/main/docs/DEVELOPMENT_ENVIRONMENT.md https://github.com/systeminit/si/blob/main/docs/DEVELOPMENT_... friend are some wowzers for just tire kicking the thing. Is there any interest or intention to offer a docker-compose.yml for a little less "I want to spend an entire day just to see this run?"
- holoway 3y ago
  Yep. If you go to https://systeminit.com https://systeminit.com and click "Sign up", you can use our launcher to run a build directly.
lijok 3y ago
So, so many questions. Let me preface this by saying - if this works well enough to give devs confidence in the tool, this could be revolutionary. It would combine implementation, documentation, visuals and deployment into a single view simple enough for everyday devs to grok. I couldn't find any documentation - if there is, that answers these questions, please link me to them. 1. How does authentication work? Is it handled by the tool? 2. Can it support non-AWS resources, such as Grafana? 3. How does version control work? Can you review changes, roll back, etc? 4. In the demo on the main site, the security group was not attached to any VPC, what's going on there? 5. Does this remain maintainable when dealing with very large configurations, for example, a multi-account AWS setup with tens of thousands of resources. If so, what mechanisms are available in this tool to facilitate this maintainability? Thank you
- holoway 3y ago
  It's very early - it doesn't do much yet (but what it does do is compelling!). There isn't a ton of documentation, but we have put a lot of real user research into things. 1. Authentication works through Auth0. We're building towards multiple deployment models, where your account works across all of them. That said, it's all open source, so if Auth0 doesn't work for someone, we're happy to make it pluggable. 2. You can model anything you like. Under the hood it's a hypergraph of Typescript functions - so you would model Grafana, and then make calls to its API when actions are needed. 3. It's built in to the model via change-sets. As you do change the model, we show you whats changed, and what actions we would take. The design is heading toward letting you have comprehensive reviews based on which portions of the entire model are impacted. Roll-backs aren't really a thing in infrastructure land, but you can see old versions of the model and decide you want that to be the current one. 4. We model the upstream 1:1 - so that configuration uses the default VPC in the AWS account (which has likely been deleted if you use Terraform, for example.) 5. It's too early to have very large configurations yet. But there are techniques we can borrow from other domains - nesting, for example, or layers. We're working on the fundamentals first, and then we will deal with scale. Great questions!
Dowwie 3y ago
What were the decisions supporting the project's use of Buck2? Considering your team is specializing in the domain of infra automation, compile times of all of SI's Rust must be a hot topic among the team.
- holoway 3y ago
  We've got a fairly large monorepo, with code primarily in Rust, Typescript and PgSQL. We wanted something that would scale as we grew into things like remote execution and build farms, but that would let us be pragmatic in the meantime. Buck2 fit the bill at the time we needed to solve the problem. We also needed it to understand cross language dependencies. One of the great things about it is that our CI system uses BXL to automatically generate pipelines on the fly from impacted code, taking into account dependencies. So things generally move as quickly as possible through the system. It's been real work to adopt, but the upside for us has been worth it.
  - dieortin 3y ago
    Any specific thing that made you choose Buck2 over Bazel?
    - holoway 3y ago
      the ability to not have sandboxed local builds meant that it was easy for us to write the starlark/python code we needed to get things working in a rough way quickly, while correctness can come later.
adamgordonbell 3y ago
Best Skid Row Album?
- holoway 3y ago
  Slave to the Grind, without question.

Was this something you had planned to announce prior to the whole Terraform kerfuffle and it is just unfortunate timing, or was this precipitated by that event in any way?

holoway 3y ago
We've been planning to open source it this way for the better part of a year. It just so happened that we were ready to open it up right after the Hashicorp folks made their decision. No intentional timing. You can see more on our approach here: https://www.systeminit.com/open-source/ https://www.systeminit.com/open-source/

mdaniel 3y ago

Apologies if this comes across as "gift horse mouth"-y but https://github.com/systeminit/si#local-development-setup https://github.com/systeminit/si#local-development-setup and its https://github.com/systeminit/si/blob/main/docs/DEVELOPMENT_ENVIRONMENT.md https://github.com/systeminit/si/blob/main/docs/DEVELOPMENT_... friend are some wowzers for just tire kicking the thing. Is there any interest or intention to offer a docker-compose.yml for a little less "I want to spend an entire day just to see this run?"

holoway 3y ago
Yep. If you go to https://systeminit.com https://systeminit.com and click "Sign up", you can use our launcher to run a build directly.

lijok 3y ago

So, so many questions. Let me preface this by saying - if this works well enough to give devs confidence in the tool, this could be revolutionary. It would combine implementation, documentation, visuals and deployment into a single view simple enough for everyday devs to grok. I couldn't find any documentation - if there is, that answers these questions, please link me to them. 1. How does authentication work? Is it handled by the tool? 2. Can it support non-AWS resources, such as Grafana? 3. How does version control work? Can you review changes, roll back, etc? 4. In the demo on the main site, the security group was not attached to any VPC, what's going on there? 5. Does this remain maintainable when dealing with very large configurations, for example, a multi-account AWS setup with tens of thousands of resources. If so, what mechanisms are available in this tool to facilitate this maintainability? Thank you

holoway 3y ago
It's very early - it doesn't do much yet (but what it does do is compelling!). There isn't a ton of documentation, but we have put a lot of real user research into things. 1. Authentication works through Auth0. We're building towards multiple deployment models, where your account works across all of them. That said, it's all open source, so if Auth0 doesn't work for someone, we're happy to make it pluggable. 2. You can model anything you like. Under the hood it's a hypergraph of Typescript functions - so you would model Grafana, and then make calls to its API when actions are needed. 3. It's built in to the model via change-sets. As you do change the model, we show you whats changed, and what actions we would take. The design is heading toward letting you have comprehensive reviews based on which portions of the entire model are impacted. Roll-backs aren't really a thing in infrastructure land, but you can see old versions of the model and decide you want that to be the current one. 4. We model the upstream 1:1 - so that configuration uses the default VPC in the AWS account (which has likely been deleted if you use Terraform, for example.) 5. It's too early to have very large configurations yet. But there are techniques we can borrow from other domains - nesting, for example, or layers. We're working on the fundamentals first, and then we will deal with scale. Great questions!

Dowwie 3y ago

What were the decisions supporting the project's use of Buck2? Considering your team is specializing in the domain of infra automation, compile times of all of SI's Rust must be a hot topic among the team.

holoway 3y ago
We've got a fairly large monorepo, with code primarily in Rust, Typescript and PgSQL. We wanted something that would scale as we grew into things like remote execution and build farms, but that would let us be pragmatic in the meantime. Buck2 fit the bill at the time we needed to solve the problem. We also needed it to understand cross language dependencies. One of the great things about it is that our CI system uses BXL to automatically generate pipelines on the fly from impacted code, taking into account dependencies. So things generally move as quickly as possible through the system. It's been real work to adopt, but the upside for us has been worth it.
- dieortin 3y ago
  Any specific thing that made you choose Buck2 over Bazel?
  - holoway 3y ago
    the ability to not have sandboxed local builds meant that it was easy for us to write the starlark/python code we needed to get things working in a rough way quickly, while correctness can come later.

adamgordonbell 3y ago

Best Skid Row Album?

holoway 3y ago
Slave to the Grind, without question.