Hacker News Reader

Comment by bilekas | Hacker News Reader

> Your team gets bogged down with complex Terraform scripts, manual configuration, and endless CI/CD pipelines.

I really hate marketing speak like this. Terraform is there specifically to solve the Aws infrastructure complexity.you create your system once and minor changes if needed.

> Flightcontrol fully automates infrastructure provisioning, CI/CD, and deployments. All within your own AWS account where you retain full visibility and control

Why does everyone think this is a desirable thing? Excluding adding to your aws price, you're now vendor locked in for your pipelines also.

I'm not seeing any benefits here for any already established company, maybe a small start-up of fresh graduates who don't want to learn Iac/DevOps ?

View on HN

> Terraform is there specifically to solve the Aws infrastructure complexity.

I don't know if anyone here remembers the Ant build system, but writing your own Terraform spaghetti strongly resembles the days of Ant, before Maven came along. Teams over-engineering their build pipeline, building "platforms" that other teams must use, an unmaintainable and untestable mess. Time better spent elsewhere.

> Teams over-engineering their build pipeline, building "platforms" that other teams must use, an unmaintainable and untestable mess. Time better spent elsewhere.

I have to disagree a little here, if you're already in AWS, then an investment in fixing your terraform structure is not just worth the money, but gives you a better understanding of the infrastructure architecture, you also retain ownership of your deployments. What happens if Flightcontrol go down for whatever reason? Or are sold off like other's we've seen, or god forbid you need some fine tuning that isn't in the Flightcontrol's website. You're now depending on, and maybe even paying for, an external company for devops support to do something you already know how to do.

It seems to be in the long term, that time is definitely not better spent elsewhere.

> What happens if Flightcontrol go down for whatever reason? Or are sold off like other's we've seen, or god forbid you need some fine tuning that isn't in the Flightcontrol's website.

These are all valid points. This is a fundamental issue with relying on non-open 3rd party solutions and (leaky) abstractions. The best solution here would be some standard that the hyperscalers implement themselves, but this is of course incredibly unlikely.

> some standard that the hyperscalers implement themselves

I'm kind of amazed that they haven't already. It would be such a good selling point for Azure, or GCP, etc. "We have a UI like Heroku or Vercel. Compare that to our confusing competitors!"

They don’t want to be easily replaceable. The closest thing to a universal interface is K8S, and thats just a small part of the overall API surface.

> the hyperscalers implement themselves

I wouldn’t be surprised to see that at some point if these tools catch on.

AWS in particular has a pattern of bringing toys everyone loves in house and making managed services out of them.

> Teams over-engineering their build pipeline, building "platforms" that other teams must use, an unmaintainable and untestable mess. Time better spent elsewhere.

This hits home so much!

I remember last year when I asked our Cloud Ops to add an additional EC2 instance and adjust sizes on two others. It took twelve work hours and resulted in +3k -2k changed lines "because they had no way of doing it now without merging seven hundred other changes.

Its an anti-pattern that negates some of the advantages of the cloud and re-introduces issues people had when things were still handled by the old internal IT infra department. I‘ve seen it a lot.

That smells like some really nasty problem in your company. If the change was really what you said it was, it might take some time and terraform code (i.e. nested submodules with hardcoded values that needs to support parameters all the way down) but it should not be a diff of that size.

Do you know what they did wrong? I would have made a stink about this.

I guess in an ideal world, a service like this would be a layer on top of Terraform. Changes in the admin page would be applied using Terraform, and update the config in your own Git repository. I think this would be much easier to sell, even if they choose to make it "write only" to avoid potential complexity of managing user defined configs.

They could get customers initially by promising a simple start to get "on the cloud", but would keep customers due to support, scaling, monitoring, ci/cd and maintenance. Cheap startups could use it as a one-time tool, but I think a lot would see the added value they bring.

Stay tuned, we’re working on the next version of Flightcontrol which is in this direction.

There are two devops patterns that WORK:

1. All centrally managed. Engineers hand off repos and devops own the instantiation. Devop is a core team with an infra monorepo.

2. Devops capable engineers are embedded into teams, and each project owns its own infrastructure with golden path guidance.

The hybrid version, central management of most stuff with project specific devops burden, is the worst of both and causes no end of problems.

Terraform isn't there to resolve the complexity of aws, it's there so you can manage tour aws deploy more easily.

In fact, terraform exposes the complexity of AWS, since with terraform you need to hook everything up manually.

And avoiding vendor lock in is an illusion. Everyone is locked in to some extent. Just design things so you can move providers by understanding your system and architecting it correctly.

Not taking advantage of extra capabilities vendors provide you is just stupid. SQS/lambda is great. Why avoid it, because one day in the far future you might move to GCP? Protip: if you move to GCP (or Oracle cloud, or IBM cloud, or CloudFlare, etc) you're going to rebuild everything anyway.

For larger companies this will get shut down, because the idea of some random team deploying to the cloud by themselves is a security breach that hasn't been reported yet.

> In fact, terraform exposes the complexity of AWS, since with terraform you need to hook everything up manually.

Clearly you've never had to deal with deploying large systems on AWS because if your account even has provisioning permissions, whish is usually a huge security risk in enterprise environments, the chances of you messing something up are all on your familiarity with Aws console. And if you get something wrong you're stranded without any kind of rollback. Terraform gives you rollback ability as well as validation against your requirements.

>Terraform is there specifically to solve the Aws infrastructure complexity

No, terraform passes AWS complexity 1:! onto you, it just allows you to tackle it in an ordered fashion.

Terraform used to solve the AWS infrastructure problem. But at a certain scale it becomes the problem.

Is this an issue with Terraform, or "infrastructure-as-code" in general?

Very much an IaC trait.

Non-ops teams in big corp / public services are often fed up by their own IT (slowness, incompetence) and want to deploy, budget lines for recruiting devops/sysops is sometimes different than software/platform licenses, even if the solution is sub-optimal.

Disclaimer I'm an SRE/sysops and went through a bunch of those projects where sometimes entire department see (often shadow) IT from contractors as the only solution moving forward.

Reply on news.ycombinator.com