chologrande

why yaml plus real code? why not just real code? does yaml ever actually provide benefits in testing like this?

I can simply run `helm install cert-manager` or `kubectl operator install cert-manager -n cert-manager --channel stable --approval Automatic --create-operator-group ` - both have dependency resolution.

Not trying to be negative here, trying to understand if there is value or functionality missing from established solutions, because it's not obvious to me.

How is this any smaller than OLM or the Operator pattern? Having trouble seeing the differentiator other than "it's different"

I work at a recently IPO'd tech company. Oxide was a strong consideration for us when evaluating on prem. The pitch lands among folks who still think "on prem.... ew".

Looks like a cloud like experience on your own hardware.

If only it were as cheap as dell...

> Had to do a lot of work to get node utilization ... higher than 50%

How is this the schedulers fault? Is this not just your resource requests being wildly off? Mapping directly to a "fly machine" just means your "fly machine" utilization will be low

oh that's nice I didn't know that! Still a stickler on yaml for code though

The blog perfectly sums up the feelings of anyone who has worked deep in jenkins. It works, but goddamn it's hard not to hate.

Dagger is the answer to jenkins woes. It's saved my sanity and made CI development tolerable again.

* Real language support. No groovy, no yaml.

* Debugging available in your native IDE tools.

* Clear docs in any language of your choice.

* Reproducible builds you can run locally. Just need docker.

This all comes with the bonus that it can actually just consume GHA yaml with some of the tooling folks have made.

How is Gitlab CI materially different from the jenkins model?

I find that the only difference is that it's YAML - so even harder to debug, and maintains the same model where you must re run an entire pipeline every commit to test functionality.

wow I can't facepalm any harder, I hadn't seen the architecture docs etc in the top level repo... and they're at the top level.

I'm just skimming, but it looks like the docs are fantastic. I've spent some time with terraform internals, and this seems like a significant improvement for a dev looking to work with this codebase. Gives a great overview to get started. well done!

1. I mean aging as a paradigm.

2. I mean I don't use ansible with any cloud, only with hardware or legacy on prem stacks - older versions of Cisco, Netapp, Vmware. I prefer a stateful system like terraform to a stateless one like ansible.

3. I like typed languages. I hate yaml. Logic in ansible playbooks (yaml) is inevitable and a nightmare at scale.

4. Having moved to a container orchestrator, all of my nodes are immutable, I do not change or modify them. Hardware and VM instances _can_ be born magically into existence. Nearly all infra providers support [cluster-api](https://cluster-api.sigs.k8s.io/) or some other autoscaling controller. Network infrastructure can now be managed with TF, so I go that route.

Hate to only shill hashi stack but packer if you must. All you need is a container runtime and linux kernel. After that you shouldn't have to think about the core node.

If you're _really_ bare metal - build the base image, boot pxe and run apt update - not much more complicated than that.

Ansible is great, but (imo) aged. Sure it's good for dealing with legacy hardware that cannot support terraform like state, but (imo) untyped yaml and excessive playbook runtimes turn into significant development drain as you scale.

Ansible solved a large problem (config management) before the kubernetes era, but containerization accomplishes the same goal for most applications before deployment.

100% - having to submit code server side to just get compilation results is the worst development loop I've ever experienced.

Sure - but where's the revenue come from?

just wait for the GPS Log 2.0 release. that thing will probably only get about 30 snags

What exactly is a "shadow IT app" ? How in the heck is _Evernote_ the top shadow IT app or related to automation and aI?

You're assuming you know the use case. We do more than serve LAMP stack. It takes more than a few playstations I can assure you.

I'm definitely not google scale, but we're global, in over 300 cities spanning ~30 countries. On an avg day we process well over 25k rps on multiple services. Simple architecture and IaC like terraform is exactly how we manage the dependencies. It's the solution, not the problem.

Mandated peer review, planned actions, and automated risk evaluation are part of our infra pipeline. This typically doesn't exist outside of software dev style pipeline.

After reading this post, I've browsed the site. I'm not sure how this is anything but significantly worse than the current model?

I've been around long enough to know that any "no code" style interface or GUI are typically the _problem_ not the solution. Regardless of the code they export, you end up with fat fingers, misclicks, forgotten UI paths to follow... Taking a software eng approach to shipping infra is a stable, known process that the infra team and the software teams can understand, no specialized GUI tool knowledge required.

I've been using the same basic terraform modules, jenkins pipelines, and infra architecture for nearly 7 years across multiple companies and numerous cloud deployments. It's not fancy but it justworks.jpg. Every time I re-use that code for a new deployment or account I save TONS of time.

Devops doesn't have to be hard. Infrastructure doesn't have to be complex. Deploying every day isn't _that_ difficult. KISS Method is key, especially when you're looking for speed. Using _less_ tools from the CNCF is better, and will let you move faster, not adding a new one.

Lots of comments here chiding OP for running or talking about this; I think there's something to learn here.

This is just a hobbyist prompt and api. If nothing else, I'd say at minimum this highlights that there are likely much larger farms that have been operating in a similar way but at larger scale for longer periods of time (but not talking about it)

It does seem like they just moved all of their infra components, and got rid of autoscaling.

Load balancing, logging, and other associated components are all still there. Almost nothing changed in the actual architecture, just how it was hosted.

I have a hard time seeing why this was beneficial.

I can't help but wonder if non-profit makes it easier to get access to or train on certain datasets/models.

Any time I see a nodejs tool aimed at systems tasks (general infrastructure, IaC, etc) I immediately disregard it. While, to be honest, I'm not sure that's a fair way to look at tools like this, it's the reality.

I always wonder at the authors motivation to use node when the majority of the ecosystem is written in golang. This is actually one of the main reasons I dont use terraform CDK right now. Why is CDK node first (I know there is golang support) when terraform is all golang?

Storage, Virtualization, and general UX are just completely different. Standard unix utilities are either not available or just different enough to make life hard.

At the risk of sounding like a tesla fanboy, this seems crazy to me. NHTSA investing significant resources into 36 crashes over the past 6 years? This seems like an impossibly low number of crashes.

Intuition tells me there must be _many_ more crashes caused by various other manufacturing defects or various other issues caused by "scant oversight".

written in javascript... noooooope

3 days later a response.

We have extensive jenkins pipelines, and the "platform team" supports multiple types of build/release models. Most of the infrastructure is written in TF. * 3 languages * 5 "types" (http/cron/flink/etc)

As such we've got huge groovy libraries that codify the build/release process.

I'm using dagger to re-implement most of these libraries, but in a way that I can test and develop locally without getting into tiny commit/rebuild hell.

Using a language like golang with an engine like buildkit behind it, allows me to more easily test each step of the pipeline, without running the whole thing.

you _can_. but _should_ you?

Ansible / Terraform are great when you're declarative, but once you start adding too much logic, things get hairy.