Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

wait what? | the case for nhite #1

Open
tomdavidson opened this issue Oct 21, 2017 · 2 comments
Open

wait what? | the case for nhite #1

tomdavidson opened this issue Oct 21, 2017 · 2 comments

Comments

@tomdavidson
Copy link

@owulveryck I just read your blog post about this project and you seem to down play it as poc or just for fun but I have a few questions anyway. No criticism, just seeking understanding and how this fits with something I would like to contrib/work on:

  • How compare / contrast to terraformctl ?
  • I do quite a bit of TF with team and do I have TF enterprise - how does this help with continuous delivery?
@owulveryck
Copy link
Member

Hello @tomdavidson,

Many thanks for your issue. This is the purpose of my posts: to get feedback, so I can decide whether a POC should die or be turned into a product.

First of all, I didn't know terraformctl. It looks like the project is a month old; same as nhite. It also looks like it is heavily related to kubernetes. Therefore, you need to set up this kind of infrastructure to take advantage of it. Anyway, I am confident that @kris-nova have done a good job and I will take a further look asap.

For the second point, let me explain what gave me the idea of the core principle:
I was working within an "ops team". The team was operating IaaS based on AWS services. The customers of the team were the business units.
We were using cloudformation. The stacks were mainly developped by our team and the business units could use them via the cloudformation service.

So far, so good.

There have been a test with terraform. I won't do the apology of terraform here, but it has obvious advantages over cloudformation.
If we want to keep the same organization (= stacks developped by the Ops) and to give autonomy to customers, the business units would need to take care of the terraform binary. This rises a bunch of problems:

  • how to keep the terraform version coherent accros the different business units;
  • how to deal with the security (terraform must have super power on the service it deals with, and with great power comes great responsability);
  • how to simply log what's done into the plateform;
  • how to make sure that business unit 1 will not destroy the work of business uint 2;
  • how to make sure that a use is not opening a security group to the whole world.
  • About CI/CD, could we simply switch the target environment by changing an env variable
  • ...

So far "nhite" do not give answer to all those questions; but it could (I think). For example you can have two services on different port numbers. One with the credentials that allows access to the production, the other one with access to the dev environment; deploying on one or the other is simply done by changing the address of the nhite server from the client perspective.

Actually, it's all about the "build vs buy". You can (I think) use terraform enterprise that; it will fit most of your needs but not all of them (and I would appreciate if you could confirm that). Or you can build a solution that would fit all your needs.
If the solution is KISS based, it is something to consider. It's the whole purpose of the poc: to see what can be done with ease to extend the idea of terraform to reach those goals.

I will let this issue opened for now, in case anybody wants to add his 2 cents.

@tomdavidson
Copy link
Author

Awesome and thank you for sharing a bit of your experience on that ops team.

Terraform Enterprise (Atlas) costs $10k per user and all of the organizations I have worked at have had a broad range of diverse users - app dev teams, not just ops teams, so it has been too expensive (especially for orgs on the AWS hype train that what to prescribe CloudFormation). Its value pitch seems targeted at ops teams that want to adopt some CI/CD. This is not aligned with my initiatives of dev teams practicing DevOps. On some levels it seems that for TF to be part of the cloud native app, it can not be guarded by only the ops or platform team. I sometimes question "my theory of TF" so I wanted to find out more. Which is why I am coming across projects such as this one and terraformctl.

I want a K8S service the gives that gives access to TF and allows TF plans to be bundled with Helm Charts and K8S Operators so they can natively interact with the Cloud APIs. Maybe TF Plans are use to create CRDs ...? I clearly do not have a complete understanding of what is involved. Prima facie, do you think this fits into the challenges you want nhite to answer?

Few other thoughts on how/where nhite fits:

how to keep the terraform version coherent across the different business units;

Does the required version help or are you thinking of something more on the side of updating the binary?

terraform {
  required_version = ">= 0.10.7"
}

how to deal with the security ... great power comes great responsibility;

Isn't this an IAM issue? I know this is a really problem just doesn't seem to be a Terraform problem.

how to simply log what's done into the platform;

Not the IaC code change in SCM, but something more along the lines of CloudTrail?

how to make sure that business unit 1 will not destroy the work of business unit 2;
how to make sure that a use is not opening a security group to the whole world.

IAM and Code Review?

simply switch the target environment by changing an env variable

More than your ci/cd job witching tf workspaces?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants