5 ms·

Show HN: Etcha – Infinite scale, serverless config management

45 points by candiddevmike 3y ago

While developing a SaaS, we needed a way to distribute configurations across a wide array machines in a distributed manner. We built Etcha as a way to build and run servers and applications using familiar Jsonnet and GitOps workflows--lint, test, build, and release.

cedws 3y ago
I've desperately wanted a modern config management tool for ages. This looks nice, although I'd need to actually use it to be able to tell if would work for me. I've worked with both Ansible and Puppet and prefer Puppet's architecture, but it is an absolute beast of a tool. Unfortunately, I think the production licensing here will limit the success. I can't see companies forking out $1,000 a year for an immature tool with no ecosystem when they could just use Ansible/Puppet/Salt. Not necessarily even because of the cost, it's just a lot of extra bureaucracy to get products approved in some places.
- candiddevmike 3y ago
  I have a few customers, the $1,000 subscription isn't a deal breaker at all. It's typically easy to get small expenses like that approved/whip out the credit card for most businesses. Additionally, you can use the software without the subscription for your personal needs or in a non-production/evaluation phase. In the next couple of weeks we'll release EtchaOS, an immutable "meta Linux distro" that bundles Etcha, systemd, and containerd/docker on different variants like Debian, Alma, Fedora and architectures like amd64 and aarch64.
  - cedws 3y ago
    Yes, I don't doubt you'll have customers. From the docs, I just don't see a compelling advantage Etcha has over existing tools that justifies the cost. Did you consider having an open beta? It might allow the ecosystem to develop while still enabling you to charge for the product later down the line. At my last job at a bank you most likely know of, getting any kind of product is a multi-month painful bureaucratic process. So engineers tend to live off the land with the stuff they can get for free, despite funds not being an issue.
    - candiddevmike 3y ago
      > Did you consider having an open beta? It might allow the ecosystem to develop while still enabling you to charge for the product later down the line. I don't think being free for personal/non production limits the ecosystem at all. Additionally, I don't appreciate rug pulls from changing free to non-free down the road, and I doubt my customers would. The pricing is what it is: ensure Etcha is sustainable and supported. Think of it as a forced OSS donation if you want. There's way more than $1,000 worth of value here.
      - cedws 3y ago
        >I don't think being free for personal/non production limits the ecosystem at all There are two aspects. The first one being that charging a nonzero amount decreases adoption, so fewer companies will publish modules and tools around it. The other is that people will generally not want to send pull requests adding features to something they have no stake in. If we take HashiCorp Packer or Ansible as an example, they have flourished as engineers send PRs extending the tools for their own purposes. Another thought that comes to mind is: what if your company disappears one day? Can you make some assurances that the source will be relicensed to allow users to maintain it? I wish your product great success. If it feels nice I may even end up getting a license in a future job myself. But I have stated my concern of missing out on all that the Ansible/Puppet community already provides.
kodama-lens 3y ago
I get some "managed ansible executor" vibes from this. And having a hard time differentiating it form the ansible approach. What advantage does this custum format vs industry standard tools? Also not entirely sure how state/sync loop is archived from what I've read in the docs. Do I have to change my app to pull config?
- candiddevmike 3y ago
  There are a few advantages with the tool: - It's Jsonnet instead of YAML/HCL. That means real functions, imports, and data structures. - It has built in testing and linting functionality - While push mode functions similar to Ansible, pull mode can scale infinitely as it's just clients pulling a text file. Ansible and friends have a lot of scaling issues with larger clients. - All of the rendering happens on the client, no need to bundle secrets. The state/sync loop is achieved by running Etcha as a service or container in pull or push mode. Etcha will periodically pull down new JWTs (or receive pushed) and diff them, run the changes or remove the commands that aren't present.
  - evulhotdog 3y ago
    Check out ansible-pull, which is installed by default with Ansible.
    - candiddevmike 3y ago
      Ansible pull is definitely an option, but it's not how most folks use Ansible in my experience (preferring Tower or adhoc run books), namely because it's harder to centrally manage and configure. Etcha creates release artifacts instead of pull down a git repo, and allows you to monitor your deployment using metrics services like Prometheus. Additionally, there is a complete webhook framework for triggering runs.
nurple 3y ago
It's nice that you've decided to throw off the golden veil of "declarative" that so many of the tools try to sell themselves as, while in practice the user still ends up attempting to write imperative logic while harangued by the declarative representation. Couple things I personally take issue with: String-embedding of code and templates is just straight up a nonstarter for me. I've seen enough dev/ops people struggle with tools like nomad and helm to know any sufficiently complex setup will inevitably become huge, opaque, usability mess. Finally, I just don't believe a "mutate the bag of state" strategy is the future of config management or DevOps tech. It's shown itself time and time again to be the weakest part of systems like salt, ansible, and puppet. I can't count the number of hours of my life that have been wasted writing code that attempted to, poorly I might add, perpetuate the lie of determinism this tooling tries to sell on top of the mutable bag of state that is an OS.
- candiddevmike 3y ago
  > String-embedding of code and templates is just straight up a nonstarter for me Can you expand on this? > Finally, I just don't believe a "mutate the bag of state" strategy is the future of config management or DevOps tech. Unfortunately that is how operating systems work (today). Even Nix struggles with state (though that's typically a bug). Properly controlling/preventing side effects with configuration management would require a new OS paradigm IMO. > I can't count the number of hours of my life that have been wasted writing code that attempted to, poorly I might add, perpetuate the lie of determinism One nice thing of Etcha is it makes testing your stuff really simple. Testing is baked into the tool, and you don't really have to write separate tests, the test is if your check passes/fails correctly after a command is changed/removed. Checkout the docs on it here for more info, it really helps with validation: https://etcha.dev/docs/guides/testing-patterns https://etcha.dev/docs/guides/testing-patterns
  - nurple 3y ago
    Re embedding, just to take one snippet from an example on your site: { always: true, change: 'echo %s > /work/helloworld' % n.getEnv('HOSTNAME'), id: 'write a file', onChange: [ 'read file', ], } This may be quite clear in its simplicity, and particularly to those familiar with etcha/jsonnet. However, what invariably happens is that you start seeing things like vars embedded in templates, embedded in the config mgmt implementation language, embedded in strings. The source of the values becomes incredibly difficult to reason about and to make changes against; does the value come from the target host's env, from the runner's env, from the packaging step's env, from a network request made by one of these stages (eg to a secret server), etc. Take a look at an example of what, IMO, is an absolutely horrid helm chart that Gitlab ships for installing their CI/CD runner: https://gitlab.com/gitlab-org/charts/gitlab-runner/-/blob/main/templates/configmap.yaml https://gitlab.com/gitlab-org/charts/gitlab-runner/-/blob/ma... Bash code, in yaml, in golang template. Besides even the most advanced IDEs failing to grok such a freak of technical nature, there's no way I would believe any dev that told me they understand what the state of their system will be given some input to this morass. In a recent position I was asked to try and make an existing nomad installation viable in a pretty standard corporate environment (not some special operational space e.g. cloudflare), and it was even worse; some configuration expansion was 5 layers deep, with 3 different templating engines, once consul templates were involved in generating an app's config, and the nomad config being env-generalized through generation by a higher-level helm-like tooling. Re state bag: I'm glad you mentioned nix, as I think it, and to a looser extent containers, really approach the issue in the only humanly-tenable fashion (again IMO): starting mutation from a known state. In a lot of cases that state is "nothing" as it's the simplest known state not only to position the beginning of some configuration flow at, but also the most straight-forward from which to deterministically derive a desired end state from. I definitely applaud having tests as a core component of your system, the problem is that you can not derive determinism from nondeterminism even with the best tests. Because you are operating over a nondeterministic bag of state, you can never guarantee that your tests provide a representation of a transfrom from any potential state to the desired end state, only for some particular input state (or set) which may or may not representative of what is found on the actual targets.
siliconc0w 3y ago
I proposed something similar at $work for edge environments where a full k8s CP doesn't make sense though I kept it pull only by polling S3 for work and pushing responses to an append only log. This uses a declarative k8s syntax so it theoretically allows workloads to be managed either way. Didn't really get traction, glad to see something like it realized even if it isn't the licensing model I'd pick
Alifatisk 3y ago
Infinite scale huh?

45 points by candiddevmike 3y ago

cedws 3y ago

I've desperately wanted a modern config management tool for ages. This looks nice, although I'd need to actually use it to be able to tell if would work for me. I've worked with both Ansible and Puppet and prefer Puppet's architecture, but it is an absolute beast of a tool. Unfortunately, I think the production licensing here will limit the success. I can't see companies forking out $1,000 a year for an immature tool with no ecosystem when they could just use Ansible/Puppet/Salt. Not necessarily even because of the cost, it's just a lot of extra bureaucracy to get products approved in some places.

candiddevmike 3y ago
I have a few customers, the $1,000 subscription isn't a deal breaker at all. It's typically easy to get small expenses like that approved/whip out the credit card for most businesses. Additionally, you can use the software without the subscription for your personal needs or in a non-production/evaluation phase. In the next couple of weeks we'll release EtchaOS, an immutable "meta Linux distro" that bundles Etcha, systemd, and containerd/docker on different variants like Debian, Alma, Fedora and architectures like amd64 and aarch64.
- cedws 3y ago
  Yes, I don't doubt you'll have customers. From the docs, I just don't see a compelling advantage Etcha has over existing tools that justifies the cost. Did you consider having an open beta? It might allow the ecosystem to develop while still enabling you to charge for the product later down the line. At my last job at a bank you most likely know of, getting any kind of product is a multi-month painful bureaucratic process. So engineers tend to live off the land with the stuff they can get for free, despite funds not being an issue.
  - candiddevmike 3y ago
    > Did you consider having an open beta? It might allow the ecosystem to develop while still enabling you to charge for the product later down the line. I don't think being free for personal/non production limits the ecosystem at all. Additionally, I don't appreciate rug pulls from changing free to non-free down the road, and I doubt my customers would. The pricing is what it is: ensure Etcha is sustainable and supported. Think of it as a forced OSS donation if you want. There's way more than $1,000 worth of value here.
    - cedws 3y ago
      >I don't think being free for personal/non production limits the ecosystem at all There are two aspects. The first one being that charging a nonzero amount decreases adoption, so fewer companies will publish modules and tools around it. The other is that people will generally not want to send pull requests adding features to something they have no stake in. If we take HashiCorp Packer or Ansible as an example, they have flourished as engineers send PRs extending the tools for their own purposes. Another thought that comes to mind is: what if your company disappears one day? Can you make some assurances that the source will be relicensed to allow users to maintain it? I wish your product great success. If it feels nice I may even end up getting a license in a future job myself. But I have stated my concern of missing out on all that the Ansible/Puppet community already provides.

kodama-lens 3y ago

I get some "managed ansible executor" vibes from this. And having a hard time differentiating it form the ansible approach. What advantage does this custum format vs industry standard tools? Also not entirely sure how state/sync loop is archived from what I've read in the docs. Do I have to change my app to pull config?

candiddevmike 3y ago
There are a few advantages with the tool: - It's Jsonnet instead of YAML/HCL. That means real functions, imports, and data structures. - It has built in testing and linting functionality - While push mode functions similar to Ansible, pull mode can scale infinitely as it's just clients pulling a text file. Ansible and friends have a lot of scaling issues with larger clients. - All of the rendering happens on the client, no need to bundle secrets. The state/sync loop is achieved by running Etcha as a service or container in pull or push mode. Etcha will periodically pull down new JWTs (or receive pushed) and diff them, run the changes or remove the commands that aren't present.
- evulhotdog 3y ago
  Check out ansible-pull, which is installed by default with Ansible.
  - candiddevmike 3y ago
    Ansible pull is definitely an option, but it's not how most folks use Ansible in my experience (preferring Tower or adhoc run books), namely because it's harder to centrally manage and configure. Etcha creates release artifacts instead of pull down a git repo, and allows you to monitor your deployment using metrics services like Prometheus. Additionally, there is a complete webhook framework for triggering runs.

nurple 3y ago

It's nice that you've decided to throw off the golden veil of "declarative" that so many of the tools try to sell themselves as, while in practice the user still ends up attempting to write imperative logic while harangued by the declarative representation. Couple things I personally take issue with: String-embedding of code and templates is just straight up a nonstarter for me. I've seen enough dev/ops people struggle with tools like nomad and helm to know any sufficiently complex setup will inevitably become huge, opaque, usability mess. Finally, I just don't believe a "mutate the bag of state" strategy is the future of config management or DevOps tech. It's shown itself time and time again to be the weakest part of systems like salt, ansible, and puppet. I can't count the number of hours of my life that have been wasted writing code that attempted to, poorly I might add, perpetuate the lie of determinism this tooling tries to sell on top of the mutable bag of state that is an OS.

candiddevmike 3y ago
> String-embedding of code and templates is just straight up a nonstarter for me Can you expand on this? > Finally, I just don't believe a "mutate the bag of state" strategy is the future of config management or DevOps tech. Unfortunately that is how operating systems work (today). Even Nix struggles with state (though that's typically a bug). Properly controlling/preventing side effects with configuration management would require a new OS paradigm IMO. > I can't count the number of hours of my life that have been wasted writing code that attempted to, poorly I might add, perpetuate the lie of determinism One nice thing of Etcha is it makes testing your stuff really simple. Testing is baked into the tool, and you don't really have to write separate tests, the test is if your check passes/fails correctly after a command is changed/removed. Checkout the docs on it here for more info, it really helps with validation: https://etcha.dev/docs/guides/testing-patterns https://etcha.dev/docs/guides/testing-patterns
- nurple 3y ago
  Re embedding, just to take one snippet from an example on your site: { always: true, change: 'echo %s > /work/helloworld' % n.getEnv('HOSTNAME'), id: 'write a file', onChange: [ 'read file', ], } This may be quite clear in its simplicity, and particularly to those familiar with etcha/jsonnet. However, what invariably happens is that you start seeing things like vars embedded in templates, embedded in the config mgmt implementation language, embedded in strings. The source of the values becomes incredibly difficult to reason about and to make changes against; does the value come from the target host's env, from the runner's env, from the packaging step's env, from a network request made by one of these stages (eg to a secret server), etc. Take a look at an example of what, IMO, is an absolutely horrid helm chart that Gitlab ships for installing their CI/CD runner: https://gitlab.com/gitlab-org/charts/gitlab-runner/-/blob/main/templates/configmap.yaml https://gitlab.com/gitlab-org/charts/gitlab-runner/-/blob/ma... Bash code, in yaml, in golang template. Besides even the most advanced IDEs failing to grok such a freak of technical nature, there's no way I would believe any dev that told me they understand what the state of their system will be given some input to this morass. In a recent position I was asked to try and make an existing nomad installation viable in a pretty standard corporate environment (not some special operational space e.g. cloudflare), and it was even worse; some configuration expansion was 5 layers deep, with 3 different templating engines, once consul templates were involved in generating an app's config, and the nomad config being env-generalized through generation by a higher-level helm-like tooling. Re state bag: I'm glad you mentioned nix, as I think it, and to a looser extent containers, really approach the issue in the only humanly-tenable fashion (again IMO): starting mutation from a known state. In a lot of cases that state is "nothing" as it's the simplest known state not only to position the beginning of some configuration flow at, but also the most straight-forward from which to deterministically derive a desired end state from. I definitely applaud having tests as a core component of your system, the problem is that you can not derive determinism from nondeterminism even with the best tests. Because you are operating over a nondeterministic bag of state, you can never guarantee that your tests provide a representation of a transfrom from any potential state to the desired end state, only for some particular input state (or set) which may or may not representative of what is found on the actual targets.

siliconc0w 3y ago

I proposed something similar at $work for edge environments where a full k8s CP doesn't make sense though I kept it pull only by polling S3 for work and pushing responses to an append only log. This uses a declarative k8s syntax so it theoretically allows workloads to be managed either way. Didn't really get traction, glad to see something like it realized even if it isn't the licensing model I'd pick

Alifatisk 3y ago

Infinite scale huh?