| I maintain the core of Koreo. I'll hit the easy question first, then the more involved questions. 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. |