Readit News$ ls -lah terraform/providers/registry.terraform.io/hashicorp/aws/5.14.0/darwin_amd64/ total 368M
Anyone have an idea of the reasons terraform needs a 370 MiB binary just to call REST APIs?
If you don't want to be burned by vendors changing the pricing model on you, don't choose a proprietary stack to build on.
If it's just the number of people who can go in the UI and press the button (when it automatically gets deployed from git anyway), or change env secrets, can't you just have a single admin account and call it "one user"? That could be a single actual person (how often do you change those things?) or could even be a single account shared by the whole team
What am I missing?
Render.com was more lenient in a model like you describe but still we have different people manage different apps and it adds up.
However we’ve been badly burned by vercel, netlify and render.com switching their pricing models to user based instead of infrastructure based pricing. We’re migrating to AWS amplify right now, which also happens to be wonderfully integrated into our wider IT landscape with an AWS landing zone, automated internal chargeback etc. It’s 90% the same for our use case and charges only for infra at standard AWS rates.
At this point I’m starting to wonder why it isn’t more popular.
The main problem: Many refugees are poorly suited for jobs in Germany’s highly skilled labor market and Germany hasn’t been very good at training them. To change that, Berlin is planning to introduce a points-based immigration system modeled on Australia’s or Canada’s next year.
On top of that Germany obviously has the same issues as other countries as well: employers just don't want to hire at the salary levels they'd need to hire at in order to fill certain positions.
At the same time, job seekers face high hurdles in a rigid labor market that protects incumbents, requires lengthy traineeships and rarely recognizes foreign degrees, often forcing even specialists to retrain from scratch.
I‘not sure where you got that from, but that’s just false. Most employers I know actively ask candidates to not submit irrelevant info like photos, gender, religion etc. in their applications as any info is a liability for an employer.
Look up AGG law and how all too easy it is to get a massive slap on the wrist for even the slightest hint of discrimination. Add PII issues on top.
An often overlooked angle is the "organizational lock-in" to the cloud. Adopting the cloud in any serious capacity with more than a handful of teams/applications means that you will eventually have to build up some basic organizational capabilities like setting up resource hierarchy (e.g. an AWS Organization with multiple accounts), an account provisioning process, federated authentication, chargeback... See https://cloudfoundation.org/maturity-model/ for an overview of these topics.
To be honest I have seen quite a few enterprise organizations that went through so much organizational pain integrating their first cloud provider that implementing a second provider is not really that exciting anymore. Now of course, if you plan on eventually leveraging multi-cloud anyway you can save yourself a lot of pain by setting things up with multi-cloud in mind from day one.
A good read on the topic is "Cloud Strategy" from Gregor Hohpe https://architectelevator.com/book/cloudstrategy/
If Google decides to back OpenTF that would be a huge deal.