This is already out of date: https://www.cncf.io/announcements/2025/05/01/cncf-and-synadi...
Readit Newstylertreat commented on Protecting NATS and the integrity of open source cncf.io/blog/2025/04/24/p... · Posted by u/tomncooper
The NATS project originally came out of CloudFoundry, and gnatsd later out of Apcera. I worked for Apcera while we were maintaining gnatsd. Docker and Kubernetes basically put that company out of business -- the founder went and started Synadia which was focused on NATS instead of container orchestration.
I think nats is a great technology for a number of use cases. It's unfortunate that it's so hard to find the resources to support and maintain open source software while paying developer salaries.
Derek put a ton of work, effort, and money into NATS.
It's a sad story to me; I don't know what the answer is to these sorts of "tragedy of the commons" type issues are.
I worked (briefly) at Apcera as well and on the NATS team as a core contributor on the project. I sympathize because it is really difficult to build a viable business around OSS. But the move to contribute it to CNCF, which put it on a stage that it simply never would have had without the foundation, and now trying to withdraw it because it is still a fledgling project is just not a good look.
The irony is how would this have played out if it _did_ turn into a thriving project under CNCF? In that scenario, the NATS brand would have substantially more value and equity. That would have made a relicensing even more impactful, made it even more difficult to claw back from CNCF, and even more controversial. Because NATS remains relatively niche, I suspect the thinking is that not enough people will really care for it to matter, but if that's the case, why not just make a proprietary fork under a new name?
I don't know how this situation doesn't result in a fork. Either the BSL will be a fork or the OSS will be a fork. But because nearly all of the contributors are Synadia employees, I don't know what this will mean for the longevity of the project.
tylertreat commented on Show HN: Koreo – A platform engineering toolkit for Kubernetes koreo.dev/... · Posted by u/tylertreat
Koreo and Kro share a lot of similarities in that both allow you to build abstractions that encapsulate a lot of complexity. For instance, in Kro you could implement a ResourceGraphDefinition that builds a "Workload" abstraction that produces a Workload CRD that, say, lets you specify a container image, a database, and a bucket. Then when you create an instance of this CRD, Kro might map this to a Lambda function, RDS instance, and an S3 bucket, perhaps using ACK for example. In Koreo, this would be a Workflow that has various ResourceFunctions which produce the Lambda, RDS, and S3 bucket. Just like with Kro, this would be triggered off of a CRD. In essence, both let a platform team (or whoever) provide high-level APIs that encapsulate resource management.
One difference is just in how the two approach doing this. Koreo takes an approach of providing primitives that can be composed or reused and, importantly, are actually testable (since testing is a first-class thing in Koreo). This lets you more easily validate automations but also makes it easier to provide "building block" like components that can be shared between Workflows.
Another difference is in how Koreo solves configuration management. Rather than relying on string templating or unstructured YAML overlays, Koreo treats configuration as structured data. This allows you to specify and tweak configurations in a predictable and typesafe way by transforming, validating, and composing them programmatically. Koreo is very much modeled after functional programming principles, so we can, for instance, define functions that validate preconditions or apply standard tags to resources in an environment. This model also enables configuration reuse and overrides across teams and environments without introducing tight coupling or duplication. Instead, we can apply configuration "layers" to build up a resource. Kro really focuses more on resource orchestration and leaves the configuration management up to the user.
We added a more extensive comparison on kro here: https://koreo.dev/compare/kro
tylertreat commented on Show HN: Koreo – A platform engineering toolkit for Kubernetes koreo.dev/... · Posted by u/tylertreat
I'd love to offer a few words of encouragement for this excellent project. This space only appears crowded to those that have already been here for a while. To everyone else, this might just be the most obvious thing to adopt for Kubernetes and they might not even have heard of Kustomize/Helm. So I would suggest two separate personas to target in the docs and communication: 1) Jaded devs that need to be convinced with detailed proof that Koreo isn't yet-another YAML tool. 2) Everyone else, to whom the pitch is that Koreo is the most obvious choice when the need is A, B, or C.
Looking forward to trying this out soon!
I also think more high level patterns would make Koreo more approachable. Real world problems and how they could be addressed with Koreo.
Really great feedback! Better examples and docs is definitely something high on the list.
tylertreat commented on Show HN: Koreo – A platform engineering toolkit for Kubernetes koreo.dev/... · Posted by u/tylertreat
why k8s ecosystem is so filled with yaml on-top-of-yaml, configuration on-top-of-configuration? where does this end? can we have less yaml, less configuration, not more?
The underlying engine is actually completely decoupled from yaml as it's really just structured data. We chose to stick with yaml for the "interface" since that is ultimately what it's managing—Kubernetes manifests. Personally, I tend to prefer keeping the configuration true to the underlying thing being configured rather than abstracting it away with DSLs, but I realize it's not for everyone.
tylertreat commented on Show HN: Koreo – A platform engineering toolkit for Kubernetes koreo.dev/... · Posted by u/tylertreat
I feel like it needs a comparison with https://kro.run/ and crossplane v2 which makes it more generic and less cluster scoped.
Also, what's interesting about Koreo is that you can actually build "meta" Workflows. That is, Workflows that produce Workflows, meaning you could implement something like Kro itself in Koreo fairly easily. This is why it's really closer to a programming language and runtime for programming Kubernetes control loops.
Koreo would also allow you to implement a workload spec such as Score rather easily for the same reason. https://score.dev
tylertreat commented on Show HN: Koreo – A platform engineering toolkit for Kubernetes koreo.dev/... · Posted by u/tylertreat
Awesome feedback, thank you!
The CLI is presently being reworked to expose that capability. Right now, you can use FunctionTest in order to validate that you get your expected outputs from an input. This works well because you can test many scenarios, including error conditions. The CLI does not currently emit the materialized manifests purely because our initial use cases needed to map values from reconciled manifests into other manifests. It is completely viable to emit the materialized manifests though.
Honestly, our ambition is to develop a tool that makes the operations and platform engineering people's lives better. Our team is comprised of software engineers who've worked in the operations and platform engineering space for a long time. It is a crowded space for sure, but I am optimistic, probably foolishly so, that we can develop something that is more pleasant for the platform folks than many of the other options.
We'd welcome any other feedback or thoughts on how to accomplish that.
> The CLI does not currently emit the materialized manifests purely because our initial use cases needed to map values from reconciled manifests into other manifests. It is completely viable to emit the materialized manifests though.
Only in cases where the values are statically known, however. If you have resources that depend on the output of another resource, then we can't know that at "template time" as you pointed out.
tylertreat commented on Show HN: Koreo – A platform engineering toolkit for Kubernetes koreo.dev/... · Posted by u/tylertreat
I thought Crossplane v2 was only a design proposal at the moment: https://github.com/crossplane/crossplane/pull/6255
But I guess there is an actual preview implementation now? https://docs.crossplane.io/v2.0-preview/
The comparison on Kro would definitely be good to include as there are quite a few similarities. I can write up more on how it compares in a bit.
Koreo and Kro share a lot of similarities in that both allow you to build abstractions that encapsulate a lot of complexity. For instance, in Kro you could implement a ResourceGraphDefinition that builds a "Workload" abstraction that produces a Workload CRD that, say, lets you specify a container image, a database, and a bucket. Then when you create an instance of this CRD, Kro might map this to a Lambda function, RDS instance, and an S3 bucket, perhaps using ACK for example. In Koreo, this would be a Workflow that has various ResourceFunctions which produce the Lambda, RDS, and S3 bucket. Just like with Kro, this would be triggered off of a CRD. In essence, both let a platform team (or whoever) provide high-level APIs that encapsulate resource management.
One difference is just in how the two approach doing this. Koreo takes an approach of providing primitives that can be composed or reused and, importantly, are actually testable (since testing is a first-class thing in Koreo). This lets you more easily validate automations but also makes it easier to provide "building block" like components that can be shared between Workflows.
Another difference is in how Koreo solves configuration management. Rather than relying on string templating or unstructured YAML overlays, Koreo treats configuration as structured data. This allows you to specify and tweak configurations in a predictable and typesafe way by transforming, validating, and composing them programmatically. Koreo is very much modeled after functional programming principles, so we can, for instance, define functions that validate preconditions or apply standard tags to resources in an environment. This model also enables configuration reuse and overrides across teams and environments without introducing tight coupling or duplication. Instead, we can apply configuration "layers" to build up a resource. Kro really focuses more on resource orchestration and leaves the configuration management up to the user.
I'd love to see the numbers for Cloud Run. It's nice for toy projects, but it's a money sink for anything serious, at least from my experience. On one project, we had a long-standing issue with G regarding autoscaling - scaling to zero sounds nice on paper, but they will not mention you the warmup phases where CR can spin up multiple containers for a single request and keep them for a while. And good luck hunting for unexplainedly running containers when there are no apparent cpu or network uses (G will happily charge you for this).
Additionally, startup is often abysmal with Java and Python projects (although it might perform better with Go/C++/Rust projects, but I don't have experience running those on CR).
This is really not my experience with Cloud Run at all. We've found it to actually be quite cost effective for a lot of different types of systems. For example, we ended up helping a customer migrate a ~$5B/year ecommerce platform onto it (mostly Java/Spring and Typescript services). We originally told them they should target GKE but they were adamant about serverless and it ended up being a perfect fit. They were paying like $5k/mo which is absurdly cheap for a platform generating that kind of revenue.
I guess it depends on the nature of each workload, but for businesses that tend to "follow the sun" I've found it to be a great solution, especially when you consider how little operations overhead there is with it.