Would you like to see SDK or Infra-as-code for Compass?

[Raghu Venkatesh]

Hello Folks, few weeks ago our PM, Josh reached out with this query regarding CLI.  As we continue to think deeply on developer experience for Compass, there are few things we would love to know further.

• Can you give us some examples of ways you interact with other GraphQL APIs today? When doing so, do you have a preferred language/stack?
• Would you consider using "Infrastructure-as-a-code" frameworks to manage Compass? If yes what's your tool of choice i.e Terraform, Ansible or others etc.

We would love to chat more with folks who are looking to automate and interact with Compass (beyond Forge). Let us know if you'd like to hop on a call sometime :)

Cheers

Raghu

[David Harper]

Having a Terraform module to create / update a component might be useful. You might want other data modules to read from the Team directory to then pass back in to the resource?

That way it could sit with your resource creation. Could loop back to some scorecard values?

[Raghu Venkatesh]

Thank you! This is super useful! Sounds like creating/managing components and scorecards are of value. Would you also care about metrics and dependency management? Is there anything else that might be of interest? Let us know if you are open for a chat! :) 

[David Harper]

Hey @Raghu Venkatesh . I mean, maybe Terraform Statistics as metrics would be good. Deployment time. Number of changes made? Drift?

Dependency Management = YES! But I'm not sure how you would be do that from Terraform. I usually like to keep that quite separated from each other, so components in different repositories generally don't have to know about each other.

[Orlando Kelly]

Would love to see a terraform provider for compass. I was actually talking to a team member about this today!! When an infrastructure or app has been created using terraform, I'd also like to create the component in Compass. This would automate our workflow for new components to be added to the system. Also when we make a change to the infra using Terraform, we could update the component in Compass, and when we destroy the resource , we could also remove the compass component as well.

Would be a very clean workflow.

[Raghu Venkatesh]

Thank you!  I commented on a similar thread above, sounds like managing components is the most immediate value that we could enable, apart from scorecards, would you like to see anything else in here? Let us know if you are open to having a chat on this :) 

[Steffen Opel _Utoolity_]

The AWS Cloud Development Kit (AWS CDK) has significant momentum over recent years and emerged as the AWS community's IaC tool of choice (and there are also CDK for Terraform and CDK for Kubernetes variations), so it would be most excellent if we could create / update a component via a construct in a CDK app.

Given the AWS CDK is built atop AWS CloudFormation, this would probably require you to implement a third-party resource type for the CloudFormation registry via the CloudFormation CLI, similar to e.g. the Opsgenie CloudFormation Resources.

The CloudFormation Command Line Interface (CFN-CLI) is an open-source tool that enables you to develop and test AWS and third-party extensions, such as resource types or modules, and register them for use in AWS CloudFormation. [...]

An extension is an artifact, registered in the CloudFormation registry, which augments the functionality of CloudFormation in a native manner. Extensions are registered by AWS, AWS Partner Network, AWS Marketplace sellers, and the developer community.

Once a say Atlassian::Compass::Component resource type is available and unlocks AWS native Compass management, you could optionally improve the resp. IaC DX with a resp. CDK construct.

[Raghu Venkatesh]

This is an interesting insight! I can see how CDK would enable a deeper integration with AWS. Quick question, I see CDK supports quite a flavor of languages i.e java, python, golang etc. do you see any potential winner here w.r.t adoption? 

[Steffen Opel _Utoolity_]

Fortunately that doesn't really matter due to the CDK being built atop jsii to 'provide a "native" experience in [all] supported languages':

jsii allows code in any language to naturally interact with JavaScript classes. It is the technology that enables the AWS Cloud Development Kit to deliver polyglot libraries from a single codebase!

A class library written in TypeScript can be used in projects authored in TypeScript or Javascript (as usual), but also in Python, Java, C# (and other languages from the .NET family), ...

This works remarkably well in general, though a bias for TypeScript still shines through here and there, notably in example coverage:

TypeScript was the first language supported for developing AWS CDK applications. Therefore, a substantial amount of example CDK code is written in TypeScript. If you are developing in another language, it might be useful to compare how AWS CDK code is implemented in TypeScript and your language of choice. This can help you use these examples.

If you want to spike a CDK construct, I recommend to checkout the projen 'Projects-as-Code' project, which provides class AwsCdkConstructLibrary for scaffolding:

A multi-language (jsii) construct library which vends constructs designed to use within the AWS CDK with a friendly workflow and automatic publishing to the construct catalog.

• Similarly, projen also provides ConstructLibraryCdk8s and ConstructLibraryCdktf classes.