How to integrate wing with other IaC frameworks?

[schosterbarak]

Hey team, Is there a guide on how to integrate wing to "legacy" stacks (terraform/cfn/cdk)?
@JamesWoolfenden and I just wondered if that's possible to use wing in parallel to existing stacks or should we dump and rewrite a tf module to get the most out of it.
For example, If i have a stack of tf spinning out the network, ecs fargate, lambdas etc(bridgecrew architecture) - can wing reference objects in it or provision it ?
if not, is there a migration path?

[schosterbarak]

This was also something @DrFaust92 mentioned to me when we discussed infrastructure-from-code.

[ShaiBer]

Hey, I can't see how Wing would be able to reference objects that are defined in TF/cfn of existing code bases.
As for CDK, that should be possible since you can import CDK constructs in Wing.

Provisioning existing parts of the app should be possible in Wing if you rewrite them in Wing. If they are CDK then you can also import in Wing.

Reg. migration path, I think the first step, which we already have now, is the ability to write new parts in Wing, and they can interact with the older parts of the system, just like a Lambda written in JS can interact with one in Python.
The second step is to allow existing runtime code to interact with infra that is written in Wing, without added compiler benefits in stitching them together. This is also partly possible today.
The third part, which we don't have, and will take time to create, is to allow infra in Wing to interact with runtime in other languages, but still get some of the compiler magic that helps with binding the two together.
The last part will be to allow to interop with many existing languages in Wing, not just JS, and do it in a very deep way (so you can use modules from these languages in Wing, and that the compiler could also output runtime code in these languages).

This is at least the un-official plan we have now.

[Chriscbr]

+1 to everything said above. The two main paths I see are:

• Import existing resources so that they are "managed" by the Wing app. This depends on what import mechanisms exist in the underlying provisioning engine (Terraform, CloudFormation, etc.) -- fortunately I think cdktf and AWS CDK both provide some mechanisms for this). This is ideal from a deployment / provisioning standpoint (have all resources owned / managed in a single place) but it can be a tedious migration process depending on how many resources you have.
• Continue managing existing resources using whatever mechanism you are using today (Terraform code, CloudFormation template, CDK stacks, etc.) but build your new Wing applications so that they just referenced the old resources where needed (so that you can e.g. call them inflight).
  • For example, you have an AWS S3 Bucket created outside of Wing, and you don't want Wing to create it as a new resource, but you do want it to be modeled as a Bucket in Wing so that it can be used inflight, and so that Wing will automatically set up least privilege access permissions to any resources that need to access the bucket. We haven't defined a mechanism for this in Wing yet, but it should be possible to support this for common resources.

[eladb]

I can see how @Chriscbr's 2nd bullet can be the right way for hosting a Wing application within an existing (or new) environment that is defined and deployed using other tools.

I suspect this use case falls under the "infrastructure as policy" feature of wing that we haven't yet flushed out.

I'll add a reference to this discussion in the tracking issue so we can make sure this is covered.

[schosterbarak]

@ShaiBer can an example of calling terraform from wing be added to the docs?

[ShaiBer]

Sure, as soon as we have it