jrudolph
Joined 11 years ago
Karma
272
Submissions
98
Member since
Mar 30
Recent submissions
Comment · 7 months ago
To be fair, GitHub has several magnitudes higher of revenue to support that. Including from companies like mine who are paying them good money and get absolutely sub-par service and reliability from them. I'd be happy for Codeberg to take my money for a better service on the core feature set (git hosting, PRs, issues). I can take my CI/CD elsewhere, we self-host runners anyway.
Comment · 3 years ago
I wouldn’t be surprised if Google aims to replace Google Deployment Manager with this, which never really got any traction. Azure has ARM, AWA has Cloudformation. Google betting big on terraform will be interesting considering the recent change to BSL.
If Google decides to back OpenTF that would be a huge deal.
Comment · 3 years ago
Getting a lot of docker hub vibes from this one. HashiCorp is course within their rights. Can't be cheap to run the registry given the obscene size of some terraform providers.
$ 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?
Comment · 3 years ago
I’m pretty confident of all the players in that market AWS is the least likely to pull that move.
Comment · 3 years ago
On netlify iirc pricing was for every git committer that was allowed to trigger a deploy.
Render.com was more lenient in a model like you describe but still we have different people manage different apps and it adds up.
Comment · 3 years ago
The appeal of a no-ops workflow for basic frontend apps is there. We’ve got a bunch of static docs sites built with vuepress and docusaurus that are a great fit for this. Not that we can’t whip up a CDN with terraform and a CI/CD pipeline with preview environments, but my team would rather spend its energy on our core product.
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.
Comment · 3 years ago
also on the same blog -> https://tracy.posthaven.com/part-i-founder-led-enterprise-sa...
Comment · 3 years ago
> German CVs basically require photos and other information
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.
Comment · 3 years ago
Other commenters have covered the workload lock-in angle pretty well. Using Kubernetes as a target platform for your application already gives you a decent shot a workload portability. Keep in mind though that some K8s APIs are leaky abstractions. You pay with lock in into K8s of course. At the end of the day, lock-in is a matter of tradeoffs.
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/
Comment · 4 years ago
notion.so, also has integrated support for mermaid diagrams, decent syntax highlighting etc.
Comment · 4 years ago
Learn from my mistakes picking up terraform as a software engineer thinking "it's just a better YAML"
Comment · 4 years ago
It's so saddening to see how the Kubernetes hype-cycle follows OpenStack and all the fundamental problems still seem unsolved. I sometimes feel like its just the same story playing out 5 years later, one layer up to the stack (IaaS -> CaaS) and with other fools to fall for it (with OpenStack it was sysadmins trying to run a control plane, with Kubernetes its devs trying to run infrastructure).
The abstractions we have available to build and run distributed systems may have improved, but they still suck in the grand scheme of things. My personal nightmare is that nothing better comes along soon.
> - Is it the networking model that is simple from the consumption standpoint but has too many moving parts for it to be implemented?
Many poor sysadmins before us have tried to implement Neutron (OpenStack Networking Service) with OvS or a bunch of half-assed vendor SDNs. Or LBaaS with HAProxy.
> - Is it the storage model, CSI and friends?
I mean, the most popular CSI for running on-premise is rook.io, which is just wrapping Ceph. Ceph is just as hard to run as ever, and a lot of that is justified by the inherent complexity of providing high performance multi-tenant storage.
> - Is it the bunch of controller loops doing their own things with nothing that gives a "wholesome" picture to identify the root cause?
Partially. One advantage the approach has is that it's conceptually simple, consistent and feels easy to compose complex behavior. The problem is that Kubernetes enforces very little structure, even basics like object ownership. The result is unbounded complexity. A lack of tooling (e.g. time travel debugging for control loops) makes debugging complex interactions next to impossible. This is also not surprising, control loops are a very hard problem and even simple systems can spiral (or oscillate) out of control very quickly. Control theory is hard. David Anderson has a pretty good treatise of the matter https://blog.dave.tf/post/new-kubernetes/
Compared to OpenStack, Kubernetes uses a conceptually much simpler model (control loops + CRDs) and does a much better job at enforcing API consistency. Kubernetes is locally simple and consistent, but globally brittle.
The downside is that it needs much more composition of control loops to do meaningful work, and that leads to exploding complexity because you have a bunch of uncoordinated actors (control loops) each acting on partial state (a subset of CRDs).
The implementation model of an OpenStack service otoh is much simpler because they use straight forward "workflows", working on a much bigger picture of global state, e.g. neutron owning the entire network layer. This makes composition less of a source for brittleness, not that OpenStack still has its fair share of that as well. Workflows are however much more brittle locally, because they cannot reconcile themselves in case things go wrong.
Comment · 4 years ago
This. To be fair that info is very hard to discover on the website (I looked it up in the docs code that generates the website because I found that easier to parse like a database of all models).
I own an L10 and am very happily running valetudo on it. Someone should make a business out of selling them pre-flashed with valetudo for a less technical audience…