Ship Constructs compatible with vanilla aws-cdk-lib/aws-eks

[sam-goodwin]

Is it possible to use these configurations as Construct libraries? I find the workflow of cloning this repo and running make to be at odds with how the rest of the AWS CDK ecosystem works. I have an existing EKS cluster deployed with the AWS CDK. I would expect a simple Construct I can instantiate and pass a reference to my aws-eks.Cluster, but this library seems to require I am using eks-blueprints (which has the same problem of diverging from standard AWS CDK practices).

new ObservabilityAccelerator(this, "Observability", {
  cluster: myCluster,
  // customize with props
});

[elamaran11]

EKS Blueprints and CDK Accelerator for EKS are opinionated and purpose built solutions for setting up EKS clusters with Day 2 ops toolings. [ObservabilityBuilder](https://github.com/aws-quickstart/cdk-eks-blueprints/blob/main/lib/builders/observability-builder.ts) is not a construct library but an extension of BlueprintsBuilder.
@shapirov103 Anything to add here?

[shapirov103]

Sam and I already discussed it on the blueprints side. I view the request as valid, e.g. reusing existing stacks with some components of the blueprints. I believe outside of the stylistic preferences and opinions on what is idiomatic in node/TS, the main obstacle was that the EKSBlueprint produced a stack rather than a construct. we don't have anything on the roadmap atm, but if there was a confirmed customer demand, we can make it happen.

[sam-goodwin]

I believe outside of the stylistic preferences and opinions on what is idiomatic in node/TS,

This is not about style. The whole reason this is even a problem to begin with is because you unnecessarily (!) diverged from AWS's CDK Construct guidelines by getting fancy and creative with your "style" choices and trying to be yet another framework.

eks-blueprints took ownership of the stack (cardinal sin - users own their stacks, not you), abandoned the underlying aws-eks.Cluster L2 Construct (isolating all users of that), then decided to go with a builder pattern which defers construction of the Stack until the end (literally backwards) and relies on a weird "addon" plugin-framework instead of just shipping Constructs that can be used in any CDK app as-per-usual.

Same problem is now getting even WORSE with this "observability accelerator" library which recommends a make tool and a weird cli-framework instead of just shipping ... you guessed it ... Constructs! I will never run make template and no one should - you are creating a mess for all your users.

Here are AWS's own guidelines. A lot of thought went into them and they solve all your use-cases:

• https://github.com/aws/aws-cdk/blob/main/docs/DESIGN_GUIDELINES.md
• https://docs.aws.amazon.com/prescriptive-guidance/latest/best-practices-cdk-typescript-iac/constructs-best-practices.html

Pay attention to the concept of L1, L2 and L3 Constructs. This is directly relevant to you.

Sam and I already discussed it on the blueprints side.

Yeah, we did, and you told me to "google the builder pattern in TS" and "I disagree with you". Bro, it's not about disagreeing with me, you're disagreeing with AWS's own vision for composable and re-usable infrastructure pieces. With that attitude, it's no wonder this EKS stuff is such a hot mess. I have no hope for any of it, especially after seeing make being recommended. It's red flag 🚩 after red flag 🚩.

[elamaran11]

I understand your disappointment but We wont support the requested feature anytime in future. We will keep you posted with this issue if things change.