|
|
|
|
|
|
by techpineapple
434 days ago
|
|
|
I’ve been really interested in understanding how these things work better, but I’m having a lot of trouble understanding the devex / UX. I _think_ the idea behind Koreo is that any user can upload some resource definition, and koreo essentially shores it up on the backend. If I say I want an s3 bucket, Kori will look at my custom resource, then maybe if I have a label a that says it’s a temporary bucket it adds yams to my resource to add a 30 day lifecycle policy to delete the resource. But I’m not sure I feel the advantage of this indirection. It feels confusing to be that the applied resource will be different from what’s in VCS, and the code feels super heavy for what you’re getting. I’ve been at like this and cross plane, and can’t quite grok why this is better than doing it in a classical programming language. But I think I’m wrong, can you help me understand? |
|
|
Everything is in-code and designed to have a "proper" SDLC lifecycle—code reviews, approvals, merges. It is designed to be used in gitops workflows.
For the more nuanced questions, here's some background: I like Kustomize and KPT a lot. In _my_ opinion, they should be your starting point. They are clean and easy to reason about tools. They do not work as well when you have more complexity. They're very painful if you've got _dynamic_ values or values you need to inject programmatically (think Helm's values.yaml).
The next important item to note: Koreo's relative value is lower if you're building highly bespoke one-offs or you do not care about having standard resource configurations / application architectures. The value is not zero, but there are lighter solutions and you should consider them instead.
Koreo is meant to model application architectures and resource capabilities. Using your example, you can build a BucketResource. That BucketResource will then ensure that S3 Buckets follow your company standards, including things like automatically handling the IAM setup and permissions for the service that uses the bucket. That lets you define required capabilities: An S3 Bucket is always tagged with the owner service and product domain. In production environments buckets must have lifecycle rules specifying a minimum 30 day retention. In development environments, you lifecycle rules are optional. The developers then only need to specify that their workload uses an S3 Bucket and it will be configured based on your company standards. But, we have designed it so that you can decide how much abstraction is right for your needs—you can directly expose the full, underlying API or you can abstract it more.
Effectively, it gives you an "easy" solution for building a PaaS that implements _your_ standards and opinionation.
Our original versions were directly implemented using go and Python. The issue is that iterating on the application models was much, much slower. This approach allows us to rapidly implement new capabilities and features, and even expose unique or experimental architectures to only certain application domains.