General questions

[foragerr]

Awesome stuff! This seems like a neat approach to bring ownership boundaries into a Terraform codebase 👍

I have some general questions (disclaimer: I've read about Layerform but haven't tried it yet, just skimmed a blog post and the readme.md):

• Why not use "ephemeral"?

  You mention "ephemeral environments" in blog posts - but in layerform docs, it seems to always be multiple "staging" environments - Is there a reason you're steering clear of the term "ephemeral"? What sets Layerform's layers apart from what's typically considered ephemeral environments in your view?

• When the base layer runs, does it also run all the layers above it? Thoughts on How to deal with potential breakages in upper layers?

  Using the example from docs, if the core team updates the EKS cluster, and runs layerform spawn, Will that also run all the layers above it, so they inherit any changes from the cluster apply?

• Are random id's managed in terraform via discipline

  In order to be able to deploy additional "staging" layers, resource names should have random strings in them to prevent clashes. Is this random naming completely hand-managed through dev-discipline? Do you have any thoughts about layerform features that would either tack on random strings or at least detect and warn about names that would potentially collide?

• To further enforce ownership boundaries, Can each layer live in a separate git repo?

  Reasons to do this, reasons to never do this?

• Use ephemeral layers as a means to enable Blue/Green deployments?

  Do you see a path towards, say standing up a "to-be-prod" layer in parallel to a "prod" layer and after completing testing/verification, making the "to-be-prod" the default layer?

Looking forward to hearing your insights!

[lucasfcosta]

Hey @foragerr, great questions! Thanks for asking them. I'll address each question in order.

1. Why not use ephemeral?

We're trying to default more to "multiple staging environments" as we go because we want it to be clear that we're not just giving people large machines in the cloud as others do. Ephemeral environments can be easily confused with ephemeral dev environments that run your text editor and apps in a large machine.

By saying "staging" it's clearer these environments are exactly like what you'd have in production and, consequently, in staging.

That said, we do need to be more consistent in how we refer to these environments. Thanks for pointing that out. By the way, PRs to the docs at https://github.com/ergomake/layerform-docs would be much appreciated! Please feel free to contribute there if you want.

2. When the base layer runs, does it also run all the layers above it? Thoughts on How to deal with potential breakages in upper layers?

No. It's the opposite: when you run the top layers, Layerform will spawn the base layers that the top layer depends on. That way, you can spin up only base layers if you want but not put any layers on top.

When you say breakage on upper layers, I guess you're referring to changes that will break applying the IaC, correct? If so, that's what we intend to build in a cloud platform later. That's the kind of feature we want to integrate with Pull Requests so we can give people an overview of their IaC plans and test them before anything gets applied.

3. Are random id's managed in terraform via discipline?

Right now, yes. And we do have plans to make this easier for people. The first thing related to that in the roadmap is giving people a meta argument with the actual random name generated by Layerform so people don't have to create random IDs themselves.

Your idea about detecting collisions up-front is also absolutely fantastic! But it might be a bit harder to implement as we need to know which names/constraints are unique for each type of resource. I would love to hear your thoughts on how you'd go about this and how you'd like to use a feature like that.

4. To further enforce ownership boundaries, Can each layer live in a separate git repo?

Yes, you could, but there would be some overhead w/ submodules and things like that to essentially pull everything that you're provisioning together. We've been discussing that feature, but it's not on the top of our priority list. I'd recommend keeping everything in the same repo right now.

I'd also love to hear your thoughts on how you'd like to do this. If that's something you'd like to contribute to the project, @vieiralucas and I would love to walk you through the codebase and help you contribute.

5. Use ephemeral layers as a means to enable Blue/Green deployments?

Yes! That's absolutely something we want to do alongside versioning of each layer. It's one of the first use cases as we were coming up with this abstraction. We've got quite a few other improvements to do in terms of stability right now though. Not the highest priority right now.

Thanks again for the excellent questions, and please let me know if you have comments or would like to contribute in any way. Would be very happy to bring you onboard if you want to open a pull request.

[bahaagalal]

Hi @lucasfcosta
Thanks for building and open-sourcing this. This is great.

We have been developing our own version of this internally in our company (minus those layers). We have been using prefixes to avoid name collisions across instances of the development environment, and we have used terraform workspaces to create, list, and destroy these environments.

We are eager to adopt your project and merge our efforts together. Let me know if you are keen to chat about this so we can discuss ideas about how to bring the project roadmap forward, especially the feature related to supporting layers from different repositories.