Serious question: How do organizations deal with having git on the critical path for deployment? Current employer actually prohibits this due to frequent outages in the git plant.
Everything you are referring to is the CI/CD pipeline. GitHub actions, Gitlab Runners, ArgoCD; they can all do some sort of gitops. Those dependencies existed before gitops anyway, so nothing new is being added.
gitlab on internal network works quite well. You can still use K8 / EKS / AKS for runners etc, just run it all on the internal network. Im always surprised at how many orgs use public platforms for their code and ci/cd.
Ummm … github is not git … if you must, keep your git stored locally and simply use webhooks to keep it synced whenever changes are merged via your forge of choice… you can, if necessary, make updates to your locally hosted repo in the event of an outage at the forge, but you’ll need a procedure to “sync back” any changes made during the outage.
Fortunately, the whole thing is git based, so you have all the tools you need to do it.
> Serious question: How do organizations deal with having git on the critical path for deployment?
You mean like storing source code? CICD pipeline definitions? Container image specs? IaC manifests? Service configuration files?
I don't think that arbitrarily drawing the line on what package version is being deployed is a rational opinion to have. I mean, look at npm's package.json. Is it ok to specify which dependency versions you bundle with your software, but specifying which version you're deploying is unheard of?
The only drawback I see in GitOps is that CICD pipelines are still lagging way behind on providing adequate visualization strategies to monitor the current state of multi-environment deployments.
It's my dream that one day I'll be able to run an AWS VPC that only has IPv6 for the private subnets and then I'll never have to worry about managing the address space or how many IP addresses each ALB consumes.
Technically, is there a reason AWS can't support allowing sophisticated users to run arbitrary extensions in RDS? The control-plane/data-plane boundaries should be robust enough that it's not going to allow an RDS extension to "hack AWS". Worst case is that AWS would have to account for the possibility of a crash backoff loop in RDS.
I understand that practically you can b0rk an install with a bunch of poorly configured extensions, and you can easily install something that hoovers up all your data and sends it to North Korea. But if I understand those risks and can mitigate them, why not allow RDS to load up extension binaries from an S3 bucket and call it a day?
If AWS wanted to broaden the available market, this would be an opportunity to leverage partners and the AWS marketplace mechanisms: Instead of AWS vouching for the extensions, allow partners to sell support in a marketplace. AWS has clean hands for the "My RDS instance crashed and wiped out my market cap" risk, but they can still wet their beak on the money flowing through to vendors. Meanwhile, vendors don't have to take full responsibility for the entire stack and mess with PrivateLink etc. Top tier vendors would also perform all the SOC attestation so that RDS doesn't lose out.
P.S. Andy, if you're reading this you should call me.
The Salt River enabled the Phoenix area to be an agricultural power house long before Columbus arrived in America. The Pima practiced irrigation agriculture and were using their crop surpluses to trade far and wide.
What's problematic is Phoenix agriculture is the focus on extremely water hungry crops like alfalfa and not really the presence of agriculture in general.
> What's problematic is Phoenix agriculture is the focus on extremely water hungry crops like alfalfa and not really the presence of agriculture in general.
This is entirely an artifact of arcane water law in the US. Any rational allocation would make alfalfa untenable there.
You are, of course, aware that the current US single payer system (Medicare) subcontracts their administration to private health insurance companies? And that the "overhead" typically discussed when talking about Medicare doesn't include said companies but is instead only the overhead of what it takes to shovel money from the IRS to private insurance companies?
No, this is not Medicare Advantage, in which Medicare just directly pays private health insurance premiums for enrollees.
It's not in this article, but I have a vague recollection from other discussions that the actual x-ray diffraction image was taken by one of Franklin's graduate students.
> That is correct, it was Gosling. This whole "controversy" is so stupid.
Graduate students aren't cited for coming up with innovations - the controversy is valid, but for some reason, people keep finding reasons to maintain a heterodox opinion.
The images weren't even shared with Watson/Crick by Franklin but by someone else.
Twinlaw's father is a super famous electrical engineer, retired professor emeritus with hundreds of papers (often as first) published author.
Be careful asking him about anything "he's published" since the mid-90s — because he often won't know anything about the topic. Instead, some grad-student lists you first to draw publicity to his own subordinate PhD / thesis.
After inventing a monumental concept in EE microchip design, you can just sort of rest on your laurels, just because of your name recognition (with permission, of course).
But after myself dropping out of grad school, decades ago, I've shared many lazy whiskeys with former colleagues, contemplating the "what if"s of two traveled old men. I regret nothing but happily engaged laziness.
> Graduate students aren't cited for coming up with innovations
Nonsense.
> the controversy is valid,
No. You can see both publications right here [1]. Watson and Crick explicitly say they are aware of the "general nature" of Franklin's results, but they are the only ones in that issue to propose the double helix structure with the specific features that explained all of the evidence, published and unpublished.
We actually recently made the decision to staff someone full time on the site just to maintain it for the community. Even the JSON file for the site gets hit hundreds of thousands of times per day...feels like it's become kind of the de-facto source of truth in the community for where to get reliable AWS pricing information and I believe its powering a pretty remarkable amount of downstream applications with how much usage its getting.
We acquired the site almost 5 years ago and want to continue to improve it for the community. If you have any cloud cost management needs, we're also able to help for our main business here: https://www.vantage.sh/
Indeed, the vast majority of Americans have no exposure to equities, or limited exposure through a 401k or a pension. "Be a shame if something happened to these meager rows in a database we've been conning you is the path to financial independence and security. Won't you think of your crumbs?" But I digress. TLDR If the equities market implodes, it'll be mostly fine. The stock market is not the economy [1] [2]. The economy is demand for goods and services.
(and I say this as someone with more exposure to the capital markets than most Americans, while hedging against irrationality, voting vs weighing machine and all that)
reply