Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Koreo – A platform engineering toolkit for Kubernetes

koreo.dev

Post reply on HN
Print view View original

31–40 of 47 posts

Re: Show HN: Koreo – A platform engineering toolkit for Kubernetes

#31

Post by tylertreat »

arccy wrote: post #4

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

Re: Show HN: Koreo – A platform engineering toolkit for Kubernetes

#33

Post by _joel »

dlahoda wrote: post #12

> Koreo is the engine that powers Konfigurate, a batteries-included developer platform for startups and scaleups. Yaml is no go for me. Gradually typed languages, with support of unkown values, like Nickel can be good.

Just get cdktf to manage the YAML, you may laugh but it's not so horrible as it sounds.

Re: Show HN: Koreo – A platform engineering toolkit for Kubernetes

#35

Post by [deleted] »

tylertreat wrote: post #24
tylertreat wrote: post #5

Earlier quoted context omitted.

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, RD…

[deleted]

Re: Show HN: Koreo – A platform engineering toolkit for Kubernetes

#36

Post by sierra1011 »

clvx wrote: post #11

I feel I've built something similar using fluxcd + cuelang. FluxCD allows having order through depends on and how you organize your Kustomization resource . I still believe the FluxCD project needs a UI that matches what you can get from the cli. CLI has so many features that you might or might not get fully from the available UI's.

Agreed. I'm hoping the old Weaveworks GUI makes a comeback in the near future under the new organisation, as it looked to do a better job than anything else I've seen so far.

Re: Show HN: Koreo – A platform engineering toolkit for Kubernetes

#37

Post by blitzar »

peterldowns wrote: post #6

Just one more YAML bro I swear trust me bro just one more meta level will solve everything just one more yaml please I promise you it's not bad just write yaml it's simple and clean just some more yaml man just one more yaml file you will certainly not regret it just add one more yaml (Congratulations on the launch, looks interesting!)

A toolkit for a toolkit for a toolkit.

Its toolkits all the way down.

Re: Show HN: Koreo – A platform engineering toolkit for Kubernetes

#38

Post by lnenad »

nikolayasdf123 wrote: post #32

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?

I think since the complexity is high and you cannot run away from that other than making a very small box that not a lot of use cases fit into. The main use case of k8s is handling more complex use cases so you'd remove a large portion of your audience by constraining the config.

Re: Show HN: Koreo – A platform engineering toolkit for Kubernetes

#40

Post by sudosteph »

nikolayasdf123 wrote: post #32

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?

Agreed. YAML was a great upgrade to traditional ini files, but its usage beyond any non-static config use case was a mistake. Not just k8s configs, but also ansible (Chef's ruby was so much better, chef just lost because it required an agent), and GitHub actions.
Post reply on HN