I built something like this at my previous startup, Pangea [1]. Overall I think looking back on our journey I'd sign up for it again, but it's not a panacea.
Here were the downsides we ran into
- Getting buy in to do everything through the repo. We had our feature flags controlled via a yaml file in the repo as well, and pretty quickly people got mad at the time it took for us to update a feature flag (open MR -> merge MR -> have CI update feature flag in our envs), and optimizing that took quite a while. It then made branch invariants harder to reason about (everything in the production branch is what is in our live environments, but except for feature flags). So, we moved that out of the monorepo into an actual service.
- CI time and complexity. When we started getting to around 20 services that deployed independently, GitLab started choking on the size of our CI configuration and we'd see a spinner for about 5 minutes before our pipeline even launched. Couple that with special snowflakes like the feature flag system I mentioned above, eventually it got to the point that only a few people knew exactly how rollouts edge cases worked. The juice was not worth the squeeze at that point (the juice being - "the repo is the source of truth for everything")
- Test times. We ran some e2e UI tests with Cypress that required a lot of beefy instances, and for safety we'd run them every single time. Couple that with flakiness, and you'd have a lot of red pipelines when the goal was 100% green all the time.
That being said, we got a ton of good stuff out of it too. I distinctly remember one day that I updated all but 2 of our services to run on ARM without involving service authors and our compute spend went down by 70% for that month because nobody was using the m8g spot instances, which had just been released.
Did you use turbo, buck or Bazel? Without monorepo tooling (and the blood, sweat, and tears it takes to hone them for your use cases), you start hitting all kinds of scaling limits in CI.
We had python scripts that generated GitLab CI/CD yaml [1]. Tooting my own horn here, but it was super cool to ship fairly fast for the first year or so. By the end, we had something like 5 MB of yaml, but in order for the GitLab SaaS backend to process it, it took something like 32 gigs of ram on their MergeRequestProcessor SideKiq worker.
They had to open a whole epic in order to reduce the memory usage, but I think all that work just let us continue to use GitLab as the number of services we grew increased. They recommended we use something called parent/child pipelines, but it would have been a fairly large rewrite of our logic.
Does anyone who's participated in M&A know how they come up with a breakup fee? I believe this one is $5 Billion (per Bloomberg), and Adobe <-> Figma was $1 Billion.
Interested to understand the modeling that goes into it.
Like everything else it's just a negotiated figure. Arguments to and fro would include the likelihood of breakup (such as regulatory risk, unforeseen events), how disruptive the whole process is and also simply how desperate the buyer or seller is.
There's no modeling, it's a punishment or incentive. The intention is to inflict financial pain.
There’s a rough baseline of “cost to be acquired” and you start there, and do some doubling or other increases.
Basically, being acquired is a pain in the assets and you want it to be worth your while to pursue it, even if it falls through, otherwise the board is looking at getting replaced.
Based on some experience, it's like a bond to appear in court. The number is mostly an arbitrary calculation designed to discourage you from not following through.
This is what we built at my last startup Pangea (except with GitLab CI/CD). It worked pretty well and I always wanted to open-source it, but alas in a startup there's never enough time.
It's not about the chip itself at all, it's about the software that runs on it. My Computer Architecture professor always used to say, nobody wants to recompile their code!
There are still binaries that were compiled in the 80s running happily on an x86 system because the chip conforming to the ISA guarantees that machine instruction will run the same as it did in the 80s.
As for "only" a different language, absolutely lots of software does this. As part of Apple's move from x86 to ARM, they implemented a software called Rosetta which translates x86 instructions into ARM (also known as emulation). The only problem with this is that there's a performance penalty you pay for the emulation, which can make using a program slower, choppier, etc.
I think there's a misunderstanding in what the settlement is about. As part of Purdue's bankruptcy, the Sackler family is voluntarily providing 6 billion dollars to help settle claims opioid victims have brought against Purdue Pharma.
As a condition to provide the 6 billion dollars, the Sackler family has asked the bankruptcy judge to not even allow any new suits against the Sacklers related to the Opioid epidemic. This is something bankruptcy courts do regular for the company Purdue Pharma, but it is irregular when it comes to the Sackler family (this is not the entity going bankrupt!)
This is the issue that went up to the Supreme Court, and the Supreme Court ruled that the protection given to the Sackler family is not something that can be given by a bankruptcy judge during the bankruptcy of Purdue Pharma.
To try to illustrate the (bad) principle with a starker hypothetical:
1. Scrooge McDuck owns a thousand different corporations that are restaurants and eateries.
2. A one-taco-stand company is in bankruptcy court, after recklessly inflicting severe food-poisoning on a dozen customers.
3. Scrooge McDuck says: "Out of the goodness of my heart, I will charitably donate $X of my personal funds to help these poor unfortunates... If you give me personal immunity to any lawsuits somehow involving recent food-poisoning problems anywhere."
4. The dozen hospitalized taco-eaters are puzzled but OK with this, since they'll at least get something. The judge shrugs and things move forward.
5. Meanwhile a million other customers of other restaurants see the news on their phones, which they have out because they're stuck on their toilets with raging diarrhea. Plus maybe a few whistleblowers that can't get work anywhere because Scrooge blacklisted them.
6. All of them are justifiably outraged that their rights to seek justice/compensation have been (partly) signed-away in the bankruptcy of some unrelated tiny taco stand case that they didn't--couldn't--participate in.
I don't understand why your analogy requires multiple taco trucks. So if I'm missing something please explain.
Otherwise, I find your analogy helpful and illustrative of my confusion. Here is the simplified analogy:
1. Scrooge owns a nasty taco truck that makes everyone sick. He runs to the bahamas and is gone.
2. A dozen customers take it to bankruptcy court and get ownership of the taco truck and Scrooge's "charitable" donation, but Scrooge would get immunity, and so would the taco truck.
3. Meanwhile, the victims that weren't in the settlement are outraged that Scrooge might be immune. Not everyone was a part of the first suit -- plus, the taco truck is still selling tacos, and people are still getting sick!
This illustrates my confusion.
To me it seems like we should shut down the taco truck, and not give it immunity. I'm kind of a utilitarian and I don't much care about Scrooge, though I wish I could take his money away and put him in jail.
But it seems like most of the people who are mad about the diarrhea are not talking about the taco truck's continued operations and immunity??? And they are chiefly concerned about Scrooge, who is no longer involved with the taco truck??? What gives?
Trucks? The lawsuit involves one discrete corporation, and its small size is underscored by how it's just one stand/kiosk. (I suppose it could be mobile, but that's not what I was thinking of.)
However same owner/investor happens to be involved in many un-enumerated companies, some of which might easily be guilty of the same problems, including ones that would normally "pierce the corporate veil" and affect investors directly.
> but Scrooge would get immunity, and so would the taco truck.
The taco-stand corporation isn't immune, it's going bankrupt paying judgements. CEO/Owner Scrooge is coming in from the sidelines to preempt a personal lawsuit, and also trying to get someone in authority to (wrongly) grant him immunity from other potential lawsuits from other claimants.
> plus, the taco truck is still selling tacos
Oh, I think I see: No, this isn't a duck-ified version of the entire national controversy, I'm just trying to illustrate the how an "immunity" grant can be bogus.
In other words, the taco-stand is not a 1:1 analogy placeholder for Purdue Pharma, you can assume it's been bankrupted into Chapter 7 and broken up and sold off.
Matt Levine is a treasure. He is tied only with Derek Lowe for being a fantastic writer who makes complex topics understandable, interesting, and enjoyable.
My question is not about the settlement; it's a question about moral judgements people have around Sacklers/Purdue, including judgements I see on this comment page. I already understand the mechanical details you've explained and they don't answer my question.
>I don't understand people who think the Sacklers are villains who destroyed lives, but Purdue should continue operating more-or-less as-is. Which is, I think, the conclusion from this settlement. If this is you, can you help me understand? Do you think there is/was a realistic way to prescribe opioids routinely and safely?
As GP noted, that is not the conclusion of the settlement - not even close. If you want to better understand comments on this page, perhaps reply to them asking for clarity?
I do believe the AWS Load Balancer Controller on Kubernetes allows for sharing a single "physical" load balancer.
You have to set a load-balancer-name annotation https://kubernetes-sigs.github.io/aws-load-balancer-controll... to tie everything together to one load balancer. There is a downside where you have to have a few other annotations be the same value across your ingresses, but once you work around that, you're good to go.
I couldn't find it easily specified in docs. This is a common use-case and part of why I avoid EKS for HTTP workloads is that I have tiny services I want to just make available and I don't want to have another full ELB sitting there. It isn't a cost thing primarily. It's that now I have another significant resource. I want all of these things on a misc LB.
Would recommend one of two things:
- 1Password/1Password Secrets Automation
- Github/Gitlab CI/CD Secrets
1Password may be easier to setup with easy CLI/UI access for secrets as well as in your CI pipeline. It's paid but I love the ergonomics of the system. It's what I do for all my personal projects.
Gitlab CI/CD secrets is what we use at my startup. The most annoying thing with Gitlab secrets is that you need to give maintainer access to use secrets in local scripting, but we've been able to work around it for now
Here were the downsides we ran into
- Getting buy in to do everything through the repo. We had our feature flags controlled via a yaml file in the repo as well, and pretty quickly people got mad at the time it took for us to update a feature flag (open MR -> merge MR -> have CI update feature flag in our envs), and optimizing that took quite a while. It then made branch invariants harder to reason about (everything in the production branch is what is in our live environments, but except for feature flags). So, we moved that out of the monorepo into an actual service.
- CI time and complexity. When we started getting to around 20 services that deployed independently, GitLab started choking on the size of our CI configuration and we'd see a spinner for about 5 minutes before our pipeline even launched. Couple that with special snowflakes like the feature flag system I mentioned above, eventually it got to the point that only a few people knew exactly how rollouts edge cases worked. The juice was not worth the squeeze at that point (the juice being - "the repo is the source of truth for everything")
- Test times. We ran some e2e UI tests with Cypress that required a lot of beefy instances, and for safety we'd run them every single time. Couple that with flakiness, and you'd have a lot of red pipelines when the goal was 100% green all the time.
That being said, we got a ton of good stuff out of it too. I distinctly remember one day that I updated all but 2 of our services to run on ARM without involving service authors and our compute spend went down by 70% for that month because nobody was using the m8g spot instances, which had just been released.
[1]: https://pangea.cloud/
reply