> I never ever again want to think about IP rules. I want to tell the cloud to connect service A and B!
Dear God this 1000 times. My eyes bleed from IP-riddled firewalls foisted upon my soul by security teams.
If I could also never NAT again, that'd be nice.
> Why do I need to SSH into a CI runner to debug some test failure that I can't repro locally?
Hey I can answer that one. Because an infra team was tasked with "make CI faster" and couldn't get traction getting the people responsible for the tests to write better tests (and often, just hit a brick wall getting higher ups to understand: "CI is slow" does not mean the CI system is slow. CI's overhead is negligible), and instead did the only thing generally available: threw money at the problem.
Now CI has a node that puts your local machine to shame (and in most startups, it's also running Linux, vs. macOS on the laptop) (hide the bill), and is racing those threads much harder.
I've seen people go "odd, this failure doesn't reproduce for me locally" and then reproduced it, locally, often by guessing it is a race, and then just repeated the race enough times to elicit it.
Also, sometimes CI systems do dumb things. Like Github Actions has stdin as a pipe, I think? It wreaks havoc with some tools, like `rg`, as they think they're in a `foo | rg` type setup and change their behavior. (When the test is really just doing `rg …` alone.)
Also, dev laptops have a lot of mutated state, and CI will generally start clean.
Those last two are typically hard failures (not flakes) but they can be tough to debug.
> Do we need IP addresses, CIDR blocks, and NATs, or can we focus on which services have access to what resources?
We need IP addresses, but there's not really a need for devs to see them. Nobody understands PTR records though. CIDR can mostly die, and no, NAT could disappear forever in Cloud 2.0, and good riddance.
Let me throw SRV records in there so that port numbers can also die.
Because it's bothering me: that graph is AWS services, not EC2 services.
I'll admit it depends a bit. We're moving to Github Actions and their runners are … slow. There are custom runners, but they're a PITA to set up. There's a beta for bigger runners, but you have to be blessed by Github to get in right now, apparently.
> I never ever again want to think about IP rules. I want to tell the cloud to connect service A and B!
Dear God this 1000 times. My eyes bleed from IP-riddled firewalls foisted upon my soul by security teams.
If I could also never NAT again, that'd be nice.
> Why do I need to SSH into a CI runner to debug some test failure that I can't repro locally?
Hey I can answer that one. Because an infra team was tasked with "make CI faster" and couldn't get traction getting the people responsible for the tests to write better tests (and often, just hit a brick wall getting higher ups to understand: "CI is slow" does not mean the CI system is slow. CI's overhead is negligible), and instead did the only thing generally available: threw money at the problem.
Now CI has a node that puts your local machine to shame (and in most startups, it's also running Linux, vs. macOS on the laptop) (hide the bill), and is racing those threads much harder.
I've seen people go "odd, this failure doesn't reproduce for me locally" and then reproduced it, locally, often by guessing it is a race, and then just repeated the race enough times to elicit it.
Also, sometimes CI systems do dumb things. Like Github Actions has stdin as a pipe, I think? It wreaks havoc with some tools, like `rg`, as they think they're in a `foo | rg` type setup and change their behavior. (When the test is really just doing `rg …` alone.)
Also, dev laptops have a lot of mutated state, and CI will generally start clean.
Those last two are typically hard failures (not flakes) but they can be tough to debug.
> Do we need IP addresses, CIDR blocks, and NATs, or can we focus on which services have access to what resources?
We need IP addresses, but there's not really a need for devs to see them. Nobody understands PTR records though. CIDR can mostly die, and no, NAT could disappear forever in Cloud 2.0, and good riddance.
Let me throw SRV records in there so that port numbers can also die.
Because it's bothering me: that graph is AWS services, not EC2 services.