CDK's twin problems are that it compiles down to CloudFormation and that AWS did a terrible job at supporting languages other than TypeScript. The latter is theoretically fixable with a native FFI library that is called from each language, but the former is too leaky of an abstraction.
In my experience, the AWS UI is actually pretty good at keyboard usability. The biggest issue with the UI is how long it can take API calls to fill in the data, and that would be the same for both the browser and a TUI.
Union employees have negotiated healthcare into long-term contracts, making it hard for those employers to switch. (Feel free to read up on so-called "Cadillac plans" during the original ACA negotiations for more details). The size of this market makes employers exiting a non-starter IMO. Any org that wants to exit will see a huge resistance to this change even if they can showcase all the common benefits.
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.
> 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.
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.
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.
reply