Honest question: Besides IT endpoint management, why does our industry continue to develop software that is leaning more and more towards containerization on Mac OS?
I’ve been a Mac user for 20 years and do a lot of docker and Kubernetes work. I recently started developing on a Linux machine that was a fourth of the price and a lot less burden for my day-to-day work.
Thanks for the reply. This is some great feedback. Our deck definitely has some future features and strategies in it, so if I go forward with the call I’ll definitely need to do some trimming down
This is all new to me so I’m not exactly sure what makes a firm large. There are 50 companies give or take in their portfolio. Less than 1b in the fund.
So much this. “Let it crash” is cargo culted too hard IMO. If a caller (being another library or end user) can be given information to correct an error, give it!
Let it crash works well for a phone system where it doesn’t make sense to call both parties back if the thing failed.
People tend to complain about HCL a lot, I think it’s a great language for infrastructure. I don’t want a “real programming language” for provisioning infrastructure. I feel like every time I’ve seen someone “need” a real programming language, that there is a _better_ way to do the task at hand with HCL.
That being said, there are some ugly bits.
1. Remote state as a data source means your infra is broken, you just don’t know it yet. Two apply’s have to occur to get your infra in the correct state, but they are separated by an arbitrary amount of time between executions. Even if you automate it with CI/CD, your second root module could be broken until run since it depends on the output of the other module.
2. Public modules are absolute garbage. Go find the best one, it’s trash. Here is why, 10-20 orgs all come in and tweak the module to work for them. You’ll often see 1-10 resources in a module (sometimes more), but the module will end up with more _input complexity_ than the underlying resources. Sometimes even more inputs than all the original resources combined! In the end, you get a module that “works” for everyone, with a half baked “DRY abstraction” for N number of organizations.
3. Organizing code is hard, because we often don’t fully consider environments/workspaces, infrastructure ownership, change management, and other sociotechnical concerns. I think Terraform and IaC in general is the epitome of Conway’s Law and when the (changing) social structure of the organization isn’t followed, the code gets harder to work with. This point is at odds with #1 above.
4. People tend to think “terraform apply” is a magic transactional boundary around your infrastructure. If it applies, it worked!!! But in reality, if modules aren’t crafted correctly they can “apply” cleanly, but still introduce an outage while they are executing.
All that said, I’m excited for the 1.0 release. I love terraform. Thanks to all (except module authors) for the hard work.
https://charm.sh/